fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) (01/05/89)
I hope someone out there has had some experience with the HCX/UX 3.0 version of unix running on an HCX-9 computer. It seems that accounting has a serious problem with the size of its data types for things like KCORE minutes and stuff like that. These values appear negative in the reports (daily and monthly) for userids with large values (i.e. the values overflow causing the sign bit to come on). I called the software support ppl and they said that the source is AT&T and they are having problems with releasing it. Also, they're beta testing 4.0 and don't really give a hoot about 3.0 bugs right now. In my opinion, that's no excuse for not helping us perform a fairly common practice in a proper way. If anyone has any ideas about patches or even why this type of faux pas was allowed into the release, please let me know. Also, I'm quite new to the unix environment (~6 months). Can someone tell me about AT&T vs Berkley as far as the history of both flavors. HCX/UX has a supposed best (or worst) of both worlds mixture. I'm also working on Sun Workstations and like some things better on them than the Harris, but I know that Sun's flavor of unix is more like Berkley, right? Sorry I sound so confounded. I am. -Cris --------------------------------------------------------------------------- | Cris Fuhrman | manager@a.coe.wvu.wvnet.edu (129.71.12.1) | | Comp Sys Manager | un020312@wvnvms.bitnet | | G-40B Eng Science Bldg. | "Just say NO to commercial file x-fers." | | WVU Morgantown, WV | - Kermit the Frog |
debra@alice.UUCP (Paul De Bra) (01/06/89)
In article <207@h.cs.wvu.wvnet.edu> fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) writes: >I hope someone out there has had some experience with the HCX/UX 3.0 >version of unix running on an HCX-9 computer. It seems that accounting >has a serious problem with the size of its data types for things like >KCORE minutes and stuff like that. These values appear negative in the >reports (daily and monthly) for userids with large values (i.e. the values >overflow causing the sign bit to come on)... This happens on all Unix systems I have seen so far (except the ones that don't run accounting:-) The kernel keeps the time in some weird format, mainly to avoid floating- point operations and still have fractional numbers. This format exists for historical reasons I believe (dating back to when float operations were slow, but that is still true for 286 and 386 boxes without coprocessor, so it still makes sense). So it is unlikely that it will be fixed in a future version of your particular Unix, unless AT&T changes the format for all future Unixes. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jcm@mtunb.ATT.COM (was-John McMillan) (01/06/89)
In article <8675@alice.UUCP> debra@alice.UUCP () writes: >In article <207@h.cs.wvu.wvnet.edu> fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) writes: ... >>has a serious problem with the size of its data types for things like >>KCORE minutes and stuff like that. These values appear negative in the >>reports (daily and monthly) for userids with large values (i.e. the values >>overflow causing the sign bit to come on)... ... >The kernel keeps the time in some weird format, mainly to avoid floating- >point operations and still have fractional numbers. This format exists for >historical reasons I believe (dating back to when float operations were >slow, but that is still true for 286 and 386 boxes without coprocessor, so >it still makes sense). Those data are REPORTED in 'comp_t' form. This is NOT a SHORT: typedef ushort comp_t; /* "floating point" */ /* 13-bit fraction, 3-bit exponent */ Notice: it is NOT EVEN SIGNED. (Would you let your sibling marry a NEGATIVE non-signed value?) If you really think the system does this to save FLOATING POINT arithmetic, I've a coupla bridges for ya ;-}. However, if you're interested in minimizing the size of accounting records, particularly dating back to those halcyon days when a 50 MB disk was often the sole large disk.... jc mcmillan -- att!mtunb!jcm -- just muttering for myself, it that
fuhrman@h.cs.wvu.wvnet.edu (Cris Fuhrman,G-40B ESB,293-2190,599-1202) (01/07/89)
From article <1356@mtunb.ATT.COM>, by jcm@mtunb.ATT.COM (was-John McMillan): > > Those data are REPORTED in 'comp_t' form. This is NOT a SHORT: > typedef ushort comp_t; /* "floating point" */ > /* 13-bit fraction, 3-bit exponent */ > Notice: it is NOT EVEN SIGNED. (Would you let your sibling marry > a NEGATIVE non-signed value?) > > If you really think the system does this to save FLOATING POINT arithmetic, > I've a coupla bridges for ya ;-}. However, if you're interested in > minimizing the size of accounting records, particularly dating back to > those halcyon days when a 50 MB disk was often the sole large disk.... > Is it possible then, that the report code is not using the correct data type? Or is it that the actual accounting records are overflowing. What I'm trying to say is, can I get any useful info at all from accounting, or is it just a waste of cpu time? Ok... Like I said, I'm new to unix. I just graduated with a bs in cs, and I had heard a lot of hype about unix from fellow computer scientists. Is it likely that people developing the new versions will realize that 50 MB sole disks are a thing of the past, and that machines are much faster and more capable to do things (accounting is an important thing) in a reasonable fashion? I can see the hype losing it's flair. It's 1989. (* flame retardant pajamas being donned *) -Cris ------------------------------------------------------------------------- | Cris Fuhrman | manager@a.coe.wvu.wvnet.edu (129.71.12.1) | | Comp Sys Manager | un020312@wvnvms.bitnet | | G-40B Eng Science Bldg. | "Just say NO to commercial file x-fers." | | WVU Morgantown, WV | - Kermit the Frog |
haral@unisol.UUCP (Haral Tsitsivas) (01/09/89)
In article <217@h.cs.wvu.wvnet.edu> fuhrman@h.cs.wvu.wvnet.edu (Cris Fuhrman,G-40B ESB,293-2190,599-1202) writes: >Is it possible then, that the report code is not using the correct >data type? Or is it that the actual accounting records are >overflowing. What I'm trying to say is, can I get any useful info >at all from accounting, or is it just a waste of cpu time? I have seen that problem too, when using our JobAcct (project/job accounting, resource chargeback system) that we market. And I am sure that the correct data types are used... However, I have only seen this problem on an HCX system and only for the kcore field. Since many systems do not even keep track of the kcore field (Sequent, ...), and kcore numbers tend to be rather high (thus messing up otherwise careful charge equations) some installations do not charge for kcore seconds. >Ok... Like I said, I'm new to unix. I just graduated with a bs in cs, and >I had heard a lot of hype about unix from fellow computer scientists. Is >it likely that people developing the new versions will realize that >50 MB sole disks are a thing of the past, and that machines are much >faster and more capable to do things (accounting is an important thing) >in a reasonable fashion? I can see the hype losing it's flair. It's >1989. >... > >| Cris Fuhrman | manager@a.coe.wvu.wvnet.edu (129.71.12.1) | >| Comp Sys Manager | un020312@wvnvms.bitnet | >| G-40B Eng Science Bldg. | "Just say NO to commercial file x-fers." | >| WVU Morgantown, WV | - Kermit the Frog | This was indeed done to preserve disk space, and you will find that some vendors are not using comp_t fields anymore (ULTRIX 2.3 uses float fields). I hope that more vendors get on that track since that eliminates the problems you are experiencing. It also makes our JobAcct software a little bit faster since we don't have to convert the comp_t field to a float. -- --Haral Tsitsivas UniSolutions Associates (213) 542-0068 ...!uunet!ashtate!unisol!haral
jcm@mtunb.ATT.COM (was-John McMillan) (01/09/89)
In article <217@h.cs.wvu.wvnet.edu> fuhrman@h.cs.wvu.wvnet.edu (Cris Fuhrman,G-40B ESB,293-2190,599-1202) writes: >From article <1356@mtunb.ATT.COM>, by jcm@mtunb.ATT.COM (was-John McMillan): ... >Is it possible then, that the report code is not using the correct >data type? Again: the DATA TYPE is NOT a standard one and requires un-compressing. The following is a 15 sec. hack that uncompresses 'comp_t' values. This is needed for consumed times > 8191/HZ seconds or other units > 8191: unsigned long uncompress(v) { return((long)v&8191)<<(((v>>13)&7)*3); } or floatf uncompress(v) { return (float)(v&8191)*(1<<(((v>>13)&7)*3)); } > Or is it that the actual accounting records are >overflowing. As I eyeball the result: 0 <= resulting values <= 8191<<21 ~= 2**34 ~= 16000000. Congratulations if you're consuming more than 16 GIGA-anything. And if you're in that ballpark, use 'funcompress()'! > What I'm trying to say is, can I get any useful info >at all from accounting, or is it just a waste of cpu time? It would be ridiculous for ME to comment upon YOUR accounting software. I hope the above 'uncompress()' routine helps you striaghten things out, tho. >Ok... Like I said, I'm new to unix. I just graduated with a bs in cs, and >I had heard a lot of hype about unix from fellow computer scientists. Is nice touch -- ^^^^^^^^^^^^^^^^^^^^^^^^^^ >it likely that people developing the new versions will realize that >50 MB sole disks are a thing of the past, and that machines are much >faster and more capable to do things (accounting is an important thing) >in a reasonable fashion? I can see the hype losing it's flair. It's >1989. It strikes me the ORIGINAL writers were WELL prepared for the future -- that they had an appropriate eye out for conserving resources, regardless of disk sizes. With time, the sizes have increased -- my PC has 190 MB -- but the lack of space never seems to be solved! Unfortunately, software authors -- such as those writing accounting packages -- sometimes fail to grasp fully what the $@%@* they're doing. Even authors who were recent bs/cs graduates and scientists with answers and philosophy to guide them (:^}). The average accounting file is read once or twice in its life: data compression is reasonable and appropriate here. An error -- such as your experience suggests exists -- is all the worse as I believe the compression feature has been present for 15 years. jc mcmillan -- att!mtunb!jcm -- muttering for himself, only
mash@mips.COM (John Mashey) (01/17/89)
In article <1358@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: ... > >It strikes me the ORIGINAL writers were WELL prepared for the future -- >that they had an appropriate eye out for conserving resources, regardless >of disk sizes. With time, the sizes have increased -- my PC has 190 MB -- >but the lack of space never seems to be solved! ... >The average accounting file is read once or twice in its life: data >compression is reasonable and appropriate here. An error -- such as your >experience suggests exists -- is all the worse as I believe the compression >feature has been present for 15 years. The code was written early in 1978; DMR came up with the comp_t format; I wrote most of the original accounting software. At the time, most BTL UNIX machines were PDP-11/70s, usually with a couple RP04s (80MB), or maybe, RP06s (170MB). Typical main memory sizes were 256KB-1024KB; the kernel was limited to 64KB of code, 64KB of data, and (sometimes) 64KB of buffer cache. The design was of course geared to saving disk space, with the following reasoning: a) Typical peak fork/exit rates were 10/second. Such rates were often seen on the big PWB/UNIX systems that provided much of the impetus for doing the accounting in the first place. b) At 32 bytes/exit, this creates: 320 bytes/sec 19,200 bytes/min 1,152,000 bytes/hour 27,648,000 bytes/day c) Of course, few systems would actually run at that rate all day. Nevertheless, even a lesser, realistic rate could eat a 6th-edition filesystem, and it was required that this package run compatibly on PWB/UNIX 1.2 (which was still 6th-edition). Recall that each file was limited to 1MB, which could be overrun in an hour.... Of course, 7th-ed files and filesystems were bigger, but they didn't increase the size of disks... d) It was highly desirable NOT to go to the next higher power-of-2, as there really existed systems where doubling the accounting space would really make it impractical to use. Why would one go to 64, rather than a smaller number? ANS: for various reasons, it was desirable to keep an integral number of acct records per 512-byte block. The issue had nothing in particular to do with floating-point conversions, unless my memory fails me, strictly space compression. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086