Recently in pcounter Category

Printing from ancient history

| 1 Comment
Over the summer we tested a lot of things, one of which was Windows 7 in the computer labs. The other thing was Office 2010 in the labs. We did learn one thing, though.

Word 2010 files printing to an HP LaserJet 9050 with the Microsoft-supplied PCL5 driver yields some straaange page-counts on the printer.

Most people wouldn't care about this, since most people only look at the printer's page-counter once a quarter if that often. We care about it since we use that number for auditing. Students only get so many pages a quarter, and PCounter allows the use of the printer's page-counter as a double-check to driver-counted pages. It'll ding the user the amount of quota for paper that came out of the printer.

We were getting cases where a file with 7 pages would cause the printer to report it had printed 593 pages. Or in one case last week, a 19 page document dinged the user 2239 pages; more paper than the printer can hold. In every case it was a DOCX file that did it, on a printer using the PCL5 driver.

The fix is to use the PCL6 driver, which we're doing now. Historically we've avoided the PCL6 driver for reasons that our lab managers haven't made clear to me. They just don't work right, apparently. There are 'some issues'. Their labs, so I've rolled with it. But we're on PCL6 since that works with Office 2010.

Then I did some digging on PCL5 vs PCL6 and came across the Wikipedia page with the timeline. PCL5c/e, the version we're using, was introduced in 1992. Wowzers. PCL6 was introduced in 1995. I guess 15 years is enough time to get a printer description language right, eh?

We go through paper

We're a University, and you'd expect that in this modern era of ipads replacing textbooks and suchlike that our paper costs would be going down. You'd be wrong. We go through a heck of a lot of paper in a quarter. Spring quarter earlier this year generated 1,899,865 pages of printing, which is actually a bit up from what we did last year. Ouch.

For a nice visual clue to what we go through in a day, here is Monday of this week:
Pages-per-hour for September 27, 2010
41,375 pages is the total for Monday. Monday is also our heaviest printing day. That spike you see between 11am and Noon is regular. We've had the 11am printing peak for years. There is a smaller spike between 1 and 2pm. This time of quarter we don't have any printing going on at 5am, though the closer we get to Finals Week the more dark-o-night printing goes on.

Pcounter for AD is cool

| 1 Comment
Part of the migration project involves moving the print environment over to Windows. One thing is clear, pcounter makes Windows printing actually work. We haven't had a chance to do anything like scale testing to see how stable it is, that'll sadly have to wait until we get enough traffic (i.e. in production).

One of the ways that pcounter helps Windows printing actually work is to rationalize the print-pooling setup. Under standard Windows printing, print pooling is not a load balancing configuration. Additional printers are used when the first printers are busy with jobs, which means that one printer will get the majority of the print jobs. PCounter does true round-robbin to spread the wear-n-tear.

Pcounter does this by creating a new printer-port type called pcounter. This allows it to get creative with how it handles talking to printers.

PCounter ports display

Hitting Configure brings up the pcounter port config dialog, which you can also get at through the pcounter tools themselves.

PCounter port config dialog

There are many types here. Three ways to talk to printers directly, direct IP, LPR, and direct-attach, and two virtual methods. "Load Balance" does what you expect, you pick a number of already configured pcounter ports to put into the list and any jobs submitted to this new port will print in a round-robin fashion to printers in this list. The "OtherPrinter" option allows you to print directly via non-Pcounter printers, but only one. This last option could be useful if you had some kind of print-to-PDF software on the server that you wanted to regulate through pcounter.

The other nifty thing we're getting into is setting up a web-based release station. We could have done this in the past with NetWare, but never got around to it. It has a lot of features we won't use (such as client-codes), but it does what we want and adds a nice feature: quota listing.

Web release web-page

That sort of quota list is a very nice thing. One thing that pcounter does NOT do that it did do with eDirectory, was put the quota as an attribute on the user object. Instead it uses a custom database. Unfortunately, this means that quota is no longer LDAP accessible, which will have some implications for some of our internal tools.

Cool stuff. I'm still working with ATUS to come up with a config everyone likes, so we'll see where we end up come fall start.

We go through paper

Spring quarter is done, and grades are turned in. Time to take a look at student printing counts.

Things are changing! Printing costs do keep rising, and for a good discussion of realities check this article from ATUS News. The numbers in there are from Fall quarter. Now I'll give some Spring quarter numbers (departmental break down is different than the article, since I'm personally not sure which labs belong to which department):

Numbers are from 3/29/09-6/17/09 (8:17am)
Total Pages Printed: 1,840,186
ATUS Labs: 51.5%
Library Printers: 22.9%
Housing Labs: 14%
Comms Bldg: 6.8%
Average pages printed per user: 152
Median pages printed per user: 112
Number of users who printed anything: 12,119
Number of users over 500 pages: 292
Number of users over 1000 pages: 7
"Over quota" pages printed: 181,756

Students get a free quota of 500 pages each quarter. Getting more when you run out is as simple as contacting a helpdesk and getting your quota upped. As you can see, 2.4% of users managed to account for 9.9% of all pages printed.

It is a common misconception that the Student Tech Fee pays for the 500 pages each student gets. In actuality, that cost is eaten by each of the departments running a student printer, which means that printing has historically been a gratis benefit. There is a proposal going forward that would change things so you'd have to pay $.05/page for upping your quota. The top print-user of this quarter would have had to have paid a bit over $69 in additional quota if we were using the pay system. If ALL of the users who went over 500 pages had to pay for their additional quota, that would have generated a bit under $9088 in recovered printing costs.

Of course, if added print quota were a cost-item it will depress that overage activity. Another curve-ball is the desire of certain departments to offer color printing, but they really want to recapture their printing costs for those printers. So far we haven't done a good job of that, but we are in the process of revising the printing system to better handle it. It'll require some identity-management code changes to handle the quota management process differently, but it is at least doable.

Once you start involving actual money in this transaction, it opens up a whole 'nother can o worms. First off, cash-handling. Our help-desks do not want to be in the business of dealing with cash, so we'll need some kind of swipe-kiosh to handle that. Also, after-hours quota-bumps will need to be handled since our helpdesks are not 24/7 and sometimes students run out of quota at 6am during finals week and have an 8am class.

Second, accounting. Not all labs are run by ATUS. Some labs are run by departments that charge lab-fees that ostensibly also support lab printing. Some way to apportion recovered printing costs to departments will have to be created. Those departments that charge lab-fees may find it convenient to apply a portion of those fees to their student's page-quota.

Third, extra-cost printing like color. PCounter allows printers to be configured to not allow the use of 'free quota' for printing. So in theory, things like color or large-format-printers could be configured to only accept paid-for quota. These devices will have a cost higher than $.05/page, perhaps even $.25/page for color, or much higher for the LFP's. It could also mean some departmental lab-managers may decide to stop accepting free-quota in their labs and go charge-only.

Fourth, carry-over of paid quota. If a student forks over $20 for added quota, that should carry over until it is used. Also, it is very likely that they'll demand a refund of any unspent print-quota on graduation. Some refund mechanism will also need to be created.

I don't know at what step the proposal is, all I know is that it hasn't been approved yet. But it is very likely to be approved for fall.

Paper paper paper

| 1 Comment
It is spring break, so I can now run nice statistics on our pcounter printers! Not all of our labs are on pcounter, so these numbers are not the total printing at WWU. However, if plans to recover printing costs by charging for quota increases go through, I expect I should have the entire campus on pcounter within 3 quarters of go-live. Students WILL find the 'free' labs. And the lab admins will notice that their printing costs go way up. And then they'll call me.

Winter quarter
Pages printed: 1,781,272
Total number of students who printed at least one page: 12,482
Average pages printed by a student: 142.6
Median pages printed: 106
The busiest printer printed 133,791 pages
Res-halls printed 255,344 pages

That's a lot of paper.

Printer stats

It has been a while since I last talked about printer statistics. Being a higher ed place of learning, we have student labs. These labs have printers. And like pretty much every place of learning I've ever spoken to, we do whatever we can to restrict printing to reasonable levels. In our case, we do this with PCounter.

For October, the sum total of pages printed (as of this morning, so it isn't ALL of October) from student printers we audit, was...

585,000 pages

That's a lot of paper.

Our busiest hour was 11:00-11:59, where 70,000 (12%) of those pages were printed.
Our second busiest hour was 13:00-13:59, where 63,000 (10%) of those pages were printed.
Our lightest hour was 4:00-4:59, where 360 of those pages were printed (the large majority from the HH154 printers).
The busiest single printer was one of the Library printers, with 48,000 pages.
The busiest lab (multiple printers) was the HH154 lab, with a combined total of 71,000 pages.
The busiest dorm printer was in the Fairhaven complex, with a total of 32,000 pages.
Of the around 22,000 active students we have, 10,509 (47.8%) of them printed at least one page from one of the audited printers.

The above comes to about 43 pages per full-time-equivalent student, or around 26 pages per active student for the month of October. The busiest user printed 892 pages in October, though only three users were over the 500 standard page-quota. Paper and toner are a significant cost of doing business.

Dorm printing

On my post about finally running vista patrickbuller asked:
So you have printers that students in the dorms can print to? Wow. Do you audit all those and charge the numbers of pages against the student?
The answer to that is that we make big use of AND Technology's PCounter product. When paired with their PrintStations, it makes a very nice way to put a lid on unrestricted 'free' printing in the dorms. The PrintStations also make sure that only jobs people want to pick up get printed, which saves a serious amount of paper.

PCounter is core to our student printing. We'll only move our NDPS/iPrint infrastructure over to OES2-linux when Pcounter is supported on that platform, not before. We'll keep a 2 node NetWare cluster around just for printing if we have to. Since accounting support is one of the features that's supposed to be in OES2-SP1, it is my hope that PCounter will support OES2-Linux within a year after SP1's release. But I haven't heard any specifics.

BrainShare Wednesday

The Wednesday keynote was, indeed, a bunch of demos. It was also mostly pointless as far as the technology I'm concerned with. Lots of GroupWise (don't care), lots and lots of PlateSpin (can't afford it), lots of Zen (not the bits I'd use).

That said, the new GroupWise WebAccess is gorgeous. I wish Exchange had their non-ActiveX pages look that good.

TUT175: RBAC: Avoiding the horror, getting past the hype
Mostly about IDM as it turned out. Only minimally interesting from an abstract viewpoint about roles in general.

TUT 277: Advanced eDirectory Configuration, new features, and tuning for performance
I learned a few things I didn't know, such as the fact that each object as an "AncestorList" attribute listing who their parent objects are. This apparently greatly speeds up searching. SP3, coming out this Summer, will have faster LDAP binds for a couple of reasons. Right now Novell is recommending 2 million objects as a reasonable maximum size for a partition for performance reasons.

And also they reiterated something I've heard before...
You know how back in the NetWare 4 days, we said to design your tree by geography at the first level, and then get to departments? Um, sorry about that. It was great back then, but for LDAP or IDM it really, really slows things down.
Yep. I took my first class for my CNA when 'Green River' was just coming out, or was just out. So I remember that.

TUT221: iPrint on Linux, what Novell Support wants you to know
A nice session from a mainline support guy about the ways people don't do iPrint on linux correctly. We're not going there until pcounter can run in linux, so this is still somewhat abstract. But, nice to know.
  • The reason that some print jobs render differently than direct-print jobs, is because of how Windows is designed. Direct-print jobs render with the 'local print provider', and iPrint jobs render with the 'network print provider'. This is a Microsoft thing, not an iPrint thing. You can duplicate it by setting up a microsoft IPP printer (assuming you're not mandating SSL like we are) and printing to the same printer with the same driver.
  • The Manager on Linux doesn't use a Broker, it uses a 'driver store'.
  • The Manager on NetWare doesn't always bind to the same broker. I didn't know that.
  • It is recommended to have only one Broker, or one driver store per tree.
  • Novell recommends using DNS rather than IP for your printer-agents, check your manager load scripts.

More printing stats, weekends

This morning I noticed on our bandwidth tracker, that our internet connection had a busier weekend than any previous this quarter (when there wasn't a Bit Torrent running). Since this week is finals week, I hypothesized that the computer lab printers would be busier than normal.

Date Pages Sat Sun Ratio
6/3-6/4 26501 9468 16994 0.557138
5/20-5/21 15002 4384 10678 0.410564
5/13-5/14 11454 3973 7481 0.531079
5/6-5/7 16963 3797 13150 0.288745
4/29-4/30 14237 3963 10274 0.385731
4/22-4/23 12202 3463 8739 0.39627
4/15-4/16 9670 3115 6555 0.47521
4/8-4/9 13418 4257 9161 0.464687
4/1-4/2 13208 4302 8732 0.492671

So, yeah. It was. 26K pages this weekend, which is 9538 pages more than the next busiest weekend. The other thing that lept out is that the work was more even. The Saturday/Sunday ratio was MUCH closer to even than the past few weekends. And the Saturday numbers are also very interesting, since it shows an output this one Saturday versus any TWO previous Saturdays.

What is also interesting are the weekends of 4/15-16 and 5/13-14. Both of these weekends had markedly reduced page outputs. I wonder why that is? I strongly suspect that the chief driver of page output on weekends is having a paper due on Monday. Perhaps the profs of this University just don't like grading papers in the middle of the month? Hmmmm.

Tags: ,

Printer statistics

It has been a while since I've done page-count stats, so I figured I'd give some. The period the below stats represent is the week 5/21-5/27. A regular week, and the week before the strange tradition of this university known as 'dead week'.

Breakdown by Hour (chart):

Breakdown by Day (chart):

Take a look at the Day chart. I like that smooth curve from Monday through Friday. Monday, Tuesday, and Wednesday have slowly decreasing page-rates, and Thursday and Friday show greatly decreasing page-rates. Miniscule printing is done on Saturday.

As for the Hourly chart, once again the trend of massive printing between 11am and Noon is shown. I'm not sure why that particular hour is popular, but it clearly is, and has clearly been so for some time.

Fun stuff!

Tags: ,