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
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
