Monday, September 21, 2009
Printing habits
Some students are going to be in for a rude, rude surprise real soon. Today alone there is a student who has printed off 210 pages. Looking at their print history, they printed off 100 copies of two specific handouts (in batches of 50), and that's 40% of their entire quota for the quarter. Once they hit the ceiling, they'll have to pay to get more. This is different from last year!
We always got a few students who rammed their head against the 500 page limit within two weeks of quarter start. I'm sure we'll get some this quarter too. There may be heated tempers at the Helpdesk as a result, but thems the breaks.
We always got a few students who rammed their head against the 500 page limit within two weeks of quarter start. I'm sure we'll get some this quarter too. There may be heated tempers at the Helpdesk as a result, but thems the breaks.
Quarter start: printing
Today is go-live for the new Microsoft/PCounter based printing system. It hasn't gone off perfectly, but most of the problems so far have been manageable. Also, it's only Monday. The true peak load for printing will be Wednesday between 11:00 and 12:00. Wednesday is when classes start.
So far the big problem is that some of the disk images used for the labs included printers they weren't supposed to, a side effect of how Microsoft does printing. All in all, it's a pretty small thing but it does ruin the clean look. The time between when Summer session stopped and when all the images had to be applied (last Friday) was the same time we get every year, but this year included major changes we haven't seen since we converted from queue-based printing to NDPS printing back around 2002. So yeah, these kinds of QA things can get dropped when under this kind of time pressure, and just plain new environment.
Also, the Library doesn't have their release stations up yet. They'll have them there by the end of the day, but the fact remains that they're on the old system until then. Due to the realities of accounting, each student was given only 50 pages this morning on the old system. Which means that some users are already whacking their heads on the limit. They'll have to go to one of the ATUS labs to print, as they're all on the new system and their quotas are much higher there. If Libraries doesn't have it by tomorrow, something will have to give.
So far the big problem is that some of the disk images used for the labs included printers they weren't supposed to, a side effect of how Microsoft does printing. All in all, it's a pretty small thing but it does ruin the clean look. The time between when Summer session stopped and when all the images had to be applied (last Friday) was the same time we get every year, but this year included major changes we haven't seen since we converted from queue-based printing to NDPS printing back around 2002. So yeah, these kinds of QA things can get dropped when under this kind of time pressure, and just plain new environment.
Also, the Library doesn't have their release stations up yet. They'll have them there by the end of the day, but the fact remains that they're on the old system until then. Due to the realities of accounting, each student was given only 50 pages this morning on the old system. Which means that some users are already whacking their heads on the limit. They'll have to go to one of the ATUS labs to print, as they're all on the new system and their quotas are much higher there. If Libraries doesn't have it by tomorrow, something will have to give.
Friday, July 24, 2009
Migrations
We'll be getting our hardware early next week. Still no ETA on the storage we need to manage things.
Also, with Server 2008R2 being released on the 14th, that allows us to pick which OS we want to run. Microsoft just made it under the bar for us to consider that rev for fall quarter. Server 2008 R2 has a lot of new stuff in it, such as even more PowerShell (yes, it really is all that and a bag of chips) stuff, and PowerShell 2.0! "Printer Driver Isolation," should help minimize spooler faults, something I fear already even though I'm not running Windows Printing in production yet. Built in MPIO gets improvements as well, something that is very nice to have.
And yet... if we don't get it in time, we may not do it for the file serving cluster. Especially if pcounter doesn't work with the rebuilt printing paths for some reason. Won't know until we get stuff.
But once we get a delivery date for the storage pieces, we can start talking actual timelines beyond, "we hope to get it all done by fall start." Like, which weekends we'll need to block out to babysit the data migrations.
Also, with Server 2008R2 being released on the 14th, that allows us to pick which OS we want to run. Microsoft just made it under the bar for us to consider that rev for fall quarter. Server 2008 R2 has a lot of new stuff in it, such as even more PowerShell (yes, it really is all that and a bag of chips) stuff, and PowerShell 2.0! "Printer Driver Isolation," should help minimize spooler faults, something I fear already even though I'm not running Windows Printing in production yet. Built in MPIO gets improvements as well, something that is very nice to have.
And yet... if we don't get it in time, we may not do it for the file serving cluster. Especially if pcounter doesn't work with the rebuilt printing paths for some reason. Won't know until we get stuff.
But once we get a delivery date for the storage pieces, we can start talking actual timelines beyond, "we hope to get it all done by fall start." Like, which weekends we'll need to block out to babysit the data migrations.
Thursday, July 23, 2009
Pcounter for AD is cool
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.
Hitting Configure brings up the pcounter port config dialog, which you can also get at through the pcounter tools themselves.
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.
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.
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.
Hitting Configure brings up the pcounter port config dialog, which you can also get at through the pcounter tools themselves.
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.
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.
Wednesday, June 17, 2009
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.
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.
Monday, May 18, 2009
Printing costs
In the most recent ATUS News there is an article about printing costs. As it happens, the page-count data is data I've taken a solid look at. Printing costs have gotten a lot of attention lately as a possible cost-savings measure, and I suspect this article's existence is due in large part to that. Yeah, we go through a lot of paper.
Updated: My figures for Winter quarter.
Updated: My figures for Winter quarter.
Labels: printing
Thursday, April 30, 2009
Windows 7 RC is out
And they're saying that Win7 will ship well before the Jan-2010 Vista timeframe mentioned before. Well, we kind of expected that. We've also been doing a lot with our network to make it more Win7 (and Vista) friendly, since we know we'll get a LOT of Win7 once it shows up for real.
The biggest concern is that Microsoft still hasn't fixed the issue that makes the Novell Client for Vista so darned slow. This is a major deal-breaker for us, so we've been informed from on high to Do Something so our Vista/Win7 clients can have fast file-serving and printing.
That "Something" has been to turn on the CIFS stack on our NetWare servers, with domain integrated login. The Vista and Win7 clients will have to turn their LanMan Authentication Level from the default (and secure) setting of, "Send NTLMv2 Response Only" to at most, "Send NTLM Response Only." The NetWare CIFS stack can't handle NTLMv2, nor will it ever. Those people who have been suffering through the NCV get downright bouncy when they see how fast it is.
Printing... we'll see. A LOT of the printing in fac/staff land is direct-IP which has no Novell dependencies. There are a few departments out there that have enough print volume that a print-server is a good idea, so I'm hoping there is an iPrint client for Win7 out pretty fast.
All in all, we're expecting uptake of Win7 to be a lot faster than Vista ever was. In this sense Win7 is a lot like Win98SE. All the press saying that Win7 is a lot better than Vista will help drive the push away from WinXP.
The biggest concern is that Microsoft still hasn't fixed the issue that makes the Novell Client for Vista so darned slow. This is a major deal-breaker for us, so we've been informed from on high to Do Something so our Vista/Win7 clients can have fast file-serving and printing.
That "Something" has been to turn on the CIFS stack on our NetWare servers, with domain integrated login. The Vista and Win7 clients will have to turn their LanMan Authentication Level from the default (and secure) setting of, "Send NTLMv2 Response Only" to at most, "Send NTLM Response Only." The NetWare CIFS stack can't handle NTLMv2, nor will it ever. Those people who have been suffering through the NCV get downright bouncy when they see how fast it is.
Printing... we'll see. A LOT of the printing in fac/staff land is direct-IP which has no Novell dependencies. There are a few departments out there that have enough print volume that a print-server is a good idea, so I'm hoping there is an iPrint client for Win7 out pretty fast.
All in all, we're expecting uptake of Win7 to be a lot faster than Vista ever was. In this sense Win7 is a lot like Win98SE. All the press saying that Win7 is a lot better than Vista will help drive the push away from WinXP.
Monday, March 23, 2009
Paper paper paper
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.
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.
Friday, October 31, 2008
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.
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.
Monday, October 20, 2008
Dorm printing
On my post about finally running vista patrickbuller asked:
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.
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.
Thursday, October 16, 2008
Finally running Vista
Why? So I can upload Vista32 drivers to the student NDPS/iPrint broker. No other reason.
It would seem that an amazingly high percentage of dorm-residents this year are running vista. Something close to 50%. So it has become rather urgent that we finally get Vista drivers into the iPrint enabled printers in their area.
Getting Vista64 drivers will be more challenging, as I don't have a V64 VM yet. :P
It would seem that an amazingly high percentage of dorm-residents this year are running vista. Something close to 50%. So it has become rather urgent that we finally get Vista drivers into the iPrint enabled printers in their area.
Getting Vista64 drivers will be more challenging, as I don't have a V64 VM yet. :P
Labels: printing
Wednesday, October 15, 2008
OES2 SP1 (public beta) has been posted
The public beta of OES2 SP1 has been posted.
I believe the NDA has lifted, but I'm not 100% on that. Will check. But, some of the new stuff in SP1:
One thing I think it is safe to say, is that even though it says "Beta4" on it, it's really a release-candidate. Only major bugs are getting quashed right now. UI freeze was a month or more ago, and strange, annoying behaviors may get "fixed in doc" rather than getting true fixes which will have to wait for SP2. Still report them anyway, since it'll go on the list to fix in the next SP.
I believe the NDA has lifted, but I'm not 100% on that. Will check. But, some of the new stuff in SP1:
- An AFP stack that doesn't suck. Or more specifically, an AFP stack that scales beyond 100 users and is eDirectory integrated.
- A new CIFS stack written by Novell, so it can scale well past the Samba limit.
- A migration toolkit in one UI, rather than a cluster of scripts.
- A new version of iFolder
- EDirectory integrated DNS/DHCP. But no eDir integrated SLP yet, open-source politics you know.
- IIRC a beta of eDir 8.8 SP4.
- The ability to put iPrint-for-Linux on NSS volumes (handy for Clustering).
- And lots more I can't remember off the top of my head.
One thing I think it is safe to say, is that even though it says "Beta4" on it, it's really a release-candidate. Only major bugs are getting quashed right now. UI freeze was a month or more ago, and strange, annoying behaviors may get "fixed in doc" rather than getting true fixes which will have to wait for SP2. Still report them anyway, since it'll go on the list to fix in the next SP.
Thursday, March 20, 2008
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...
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.
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.
Labels: brainshare, edir, linux, microsoft, netware, novell, OES, pcounter, printing
Thursday, June 28, 2007
Novell iPrint and Vista
Novell has a TID:
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3288691&sliceId=SAL_Public&dialogID=39375570&stateId=0%200%2039383497
In short, Vista has native IPP support. Unlike Linux, Vista's native IPP support supports both SSL and Authentication. So out of the box Vista can print to iPrint printers. It can't do the nifty automatic setup through a web page like iPrint allows, but at least it can print.
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3288691&sliceId=SAL_Public&dialogID=39375570&stateId=0%200%2039383497
In short, Vista has native IPP support. Unlike Linux, Vista's native IPP support supports both SSL and Authentication. So out of the box Vista can print to iPrint printers. It can't do the nifty automatic setup through a web page like iPrint allows, but at least it can print.
Monday, June 05, 2006
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.
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: printing, pcounter
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: printing, pcounter
Friday, June 02, 2006
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: printing, pcounter
Breakdown by Hour (chart):
Hour | Pages |
0-1 | 1681 |
1-2 | 869 |
2-3 | 674 |
3-4 | 519 |
4-5 | 237 |
5-6 | 254 |
6-7 | 441 |
7-8 | 2613 |
8-9 | 5406 |
9-10 | 10818 |
10-11 | 10495 |
11-12 | 15488 |
12-13 | 12977 |
13-14 | 12546 |
14-15 | 11793 |
15-16 | 9704 |
16-17 | 6803 |
17-18 | 5035 |
18-19 | 4804 |
19-20 | 5111 |
20-21 | 4835 |
21-22 | 4983 |
22-23 | 3584 |
23-24 | 2962 |
Breakdown by Day (chart):
Date | Pages |
5/21 | 10618 |
5/22 | 30144 |
5/23 | 28368 |
5/24 | 27221 |
5/25 | 22417 |
5/26 | 13051 |
5/27 | 2815 |
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: printing, pcounter