In addition to the fine responses about the usual benefits of flextime (reduced traffic, lunchroom congestion, and LAN loading), I'd like to add another psychological benefit:
At work, a few induhviduals make a point of watching others comings and goings. Perhaps they imagine themselves supervisors. Their not-so-subtile looks and gossip create a negative working environment.
By going to flextime, these negative busybodies have a much tougher job keeping up. Usually, they are not capable of it.
RAMBUS has gone for high frequencies: 800 MHz x 16bits = 1.6 GB/s peak. But 800 MHz isn't easy to design onto working PCBs. Tough enough on silicon dies, and mobo's had plenty of grief just getting to 100 MHz a few years ago. 800 is a big stepout.
Every trace has to be fully simulated, none of the usual cut'n'try. Can you say data-dependant crosstalk? Sure you can! Getting close to where you need to use wave-guide techniques.
The current slew rate (Amps/ns) to drive the traces is also proportionately higher, and it isn't easy to build such low ESR capacitance.
Just because you can run 100 MHz over 100m of clothesline (oops, I mean quality Cat5 cable) doesn't mean you can run 800 MHz over 10cm of traces. Balanced lines might help, but then you double the pincount.
But you ask a good question that deserves a serious answer: Yes, it should be possible to implement portable run-time cache blocking. Two parts: First the cache detection; second, break the code into variable sized blocks.
Portable cache detection isn't quick, but it is easy: Allocate a big hunk'o'RAM bigger than expected caches. Initialize it to get off the CoW zeropage. Time repeated (10 minimum) variable length rips. Start with 1KB so you will be on-scale with gettimeofday(). Step up by powers of two, keeping careful note of gettimeofday() results. There will be big steps when you cross cachesize boundaries. Even a simple programmed algorithm can find these. The whole process will cost at least one second, and perhaps 10.
The second part, variable sized blocks complicates the code considerably. You nest the base code inside a loop and that base code has a smaller dataspan plus an offset updated in the outerloop. Inner and outer loopcounts tuned to cachesize by automagic cache detection.
Erm... my wife has the UPS. She _hates_ it when MS-Windows95b crashes due to the rotten power around here [Houston] - 1-2 dips/month. Believe it or not, I can keep her box [sic] stable iff she'll let me near it for the preventative maintenance it requires:)
SoftUpdates is not a new filesystem. *BSD still uses the same FFS it always has. It's just a flag to modify OS behaviour.
Simplified, SoftUpdates is nothing more than ordered writes: Data hits the disk before metadata is altered. And lower level metadata is written before higher level. So when powerfail happens, there may be some unattached inodes, but chains are not broken. They just have old data.
Tux2 is a whole new "Phase Tree" filesystem. That means that both the FS proper and the tree algorithm have to be debugged in parallel. Fun!
IMHO, *BSD with it's "soft updates" by Kirk McKusick is far superior to Linux ext2 in crash fs corruption resistance. I deliberately hit the power-bar off switch during four FreeBSD 3.3 kernel SMP compiles fairly late in the process
(78 sec total vs 125 sec Linux 2.2.14) to make sure that data was going to disk.
In all four cases I ran, the fsck upon repowering was fast, minor and automatic, mostly freeing unattached blocks whose metadata presumably wasn't fully written at powerout. More surprising, in three of the four trials, `make -j 4` _resumed_ the compile and as best as I could tell completed the interrupted kernel compiles without error. (Same ksize. md5 doesn't work because of timestamp) About 30-45 seconds
worth of data was lost in dirty buffers at poweroff. In the fourth case, I got compile errors, but only had to `make clean`.
I am seriously impressed. I've had poweroffs during Linux kernel compiles and had manual fsck work to do. There some info at Kirks's site http://www.mckusick.com/softdep/index.html
and there's a very interesting paper whose URL I don't have handy.
Absolutely! This technique is called "cache blocking" -- break up data into cache-sized chunks and process a sub-frame then stitch subframes together. Not easy programming, but definitely worthwhile.
Much faster than any "natural order" long array ripping unless the processing is really minor in which case main RAM bandwidth rulez.
Re:Copyright? D@mnright!
on
Deja For Sale
·
· Score: 1
It's not the archive transfer that would necessarily violate copyright. The deal could include the hardware, and there would be no copyright violation.
But I'm presuming the buyer might want to make some money:) By maybe charging for archive retrieval. _Then_ the copyright violations commence.
Re:Copyright? D@mnright!
on
Deja For Sale
·
· Score: 1
Sure they can play gamers with non-Berne Convention countries. It won't save them from copyright violations.
I could demand royalties whenever they retrieve my posts for a paying customer. They're copying an publishing my work for their profit. If they or that customer are in the US or other BerneC country, I can probably "attach" that payment.
It's not FUNNY. My posts to USENET are in DejaNews. AFAIK, I still hold copyrights whether I marked them (Copyright 2000 ) or not. So does everyone else unless the copyrights in their country of posting don't give them copyright. Maybe even then, because US law does. IANAL.
There are exemptions under copyright for the intended transmission, and reduced damages because I don't mark my posts (C), but they're still copyright. If DejaNews or whomever buys them starts charging, I want a cut!
That said, other posters have commented on how an archive should be funded, and I agree it's a thorny issue. Much as I dislike gov't involvement, this seems a natural for the Library of Congress. Or maybe you would like an ICANN spinoff?
Are there too many external connections so that the peripheral space for pin connect is at a premium? IIRC the EV6 protocol needs 64 data pins, 48 address pins plus who knows how many control signals. Say 140 per device, of which there are at least 3-4 (CPU1, CPU2, RAM & AGP/PCI). 560 plus powers/grounds.
Yup, they could be short of pin pad peripheral space, and have free silicon. Note that they cannot just simply manufacture in bigger process because it won't be fast enough.
I love the Alpha processor, but it needs a shrink in the worst imaginable way:
A 0.35um 600 MHz 21264 sucks back 47A @ 2.35V = 109 W! The things desolder themselves (apocryphal). In 0.18um, 600 MHz would only be ~16A @ 1.6V = 26W leaving plenty of room to go up to the coveted GHz (26A@1.6=43W).
Is Compaq trying to kill this processor by denying it a shrink? Sorry, the font on that URL was too small to read.
Information capacity of a channel is a function of it's Signal-to-Noise ratio. Higher S/N means you can encode more symbols per cycle. bits/Hz > 1. Modems above 2400 baud have been doing this for years. Gigabit ethernet over copper does this too.
Civil dicovery process is an awe-inspiring process. You get everything. But under the rules, are you allowed to publish what you find, or only that small portion that was admitted into evidence? What does your lawyer say?
You have made some incorrect assumptions. When I was much younger, I most certainly was taunted and subjected to verbal unpleantries. Also physical violence from my peers.
It was then that I discovered the stark difference between words and actions. Words can be ignored. Assault cannot. The impact words make is entirely up to your thinking processes. The impact punches have is a matter of physiology.
I'm afraid I respectfully disagree. I see little wrong with flaming, although I certainly won't indulge in the practice myself. Flamers reveal more about themselves than their targets.
While everybody might lose their temper every now and again, it isn't something to be proud of, nor does it win any points. USENET and the WWW should be read with large doses of skepticism.
I object to the term "verbal violence". That term should be reserved for credible threats of violence. Mere vitriol causes no harm other than hurt feelings. For those, I suggest growing a thicker skin, or getting some self-confidence.
Granted AOL/TW have denied 75%. But look at who does what, and is 75% unreasonable? It sure sounds usurious, but who provides what service?
If TW supplies all the hardware and the upstream connection, what is there left for the ISP to do but run POP, SMTP servers and maybe host some user webpages plus maybe answer a helpless desk? Then IMHO, 75% might be high but reasonable.
AFAIK, the biggest single cost for ISPs is their incoming lines and modem banks. Gone with cable. But if the ISPs still have to supply all the upstream bandwidth (routers in their shops), then 75% is ridiculous. Upstream bandwidth is the second biggest cost.
TW had better tread carefully here, or they will get themselves re-regulated.
Europe and Japan already have metering... it's by the local phone company who charge for local phone calls by the minute. I've lived there, and it s#x. IMHO, it has caused slower I'net adoption and reduced usage.
Oh, I fully agree that Soft-Updates are not a panacea. They cannot recover from matadata corrupted by a powerfail in the middle of an inode write (assuming disks don't have hw PF logic not to start a write they cannot complete).
But they greatly decrease the window of vulnerability from up to 15 seconds for sync down to approx 1 ms for an inode overwrite. Thats a very large and valuable reduction.
Orthogonally, you can mount / and/usr (but not/home) as `noatime` to cut the metadata writes considerably.
For similar crash protection, you might want to try out McKusick's "Soft Updates" that appear in *BSD systems. Essentially, they are ordered disk writes that makes sure data gets on the disk before metadata is altered. They go through the buffereing system, so performance isn't bad.
As an experiment, I pulled the plug towards the end of 5 FreeBSD kernel compiles (SMP `make -j 4`). In all cases, the fsck upon restart was minor, just freeing inodes. In four of the cases, `make` just picked up where it left off, and finished the kernel compile, losing only ~40 seconds work. In one case, a `make clean` had to be done because something was incomplete.
Don't try this on Linux! The ext2 fsck is horrible after a powerfail, and I've lost superblocks and had to re-install:( .
Interesting. Very much as I thought. I guess the frustration is all-the-higher because at the time (1990) MS was the little guy and IBM was still Big Bad Blue.
So IBM really couldn't gain any support even though MS was in the wrong.
I do not believe the Luddites were factory workers. They were the country weavers who competed against the factories. Any assaulted factory worker of course is right to defend. But smashing machines in not defense -- it is offense.
Sadly, you are probably right about the state of human rights in England at that time. But it is singularly inappropriate for them to have directed their violence specifically for their own gain. They ceded the moral high ground.
Close, but no cigar. It's OK to fight in defense or against oppression by force. It's not OK to fight for financial advantage over others.
Fighting against taxation is OK because taxation is legalized theft/extortion backed by govenment use of force. You are just defending yourself against govt force. Fighting against mill owners is RONG because they have used NO physical force against you at all.
The weavers were trying to stop their competition by violence (invading and smashing factories). Pastorial window-dressing aside, I can understand why the weavers fought. I cannot understand why anyone else would take their side.
They were trying to force cloth customers to buy from them at higher prices rather than the spinning jenny factories.
Compliance with such uses of force is NEVER good for society as a whole.
Slashdot Mirror
In addition to the fine responses about the usual benefits of flextime (reduced traffic, lunchroom congestion, and LAN loading), I'd like to add another psychological benefit:
At work, a few induhviduals make a point of watching others comings and goings. Perhaps they imagine themselves supervisors. Their not-so-subtile looks and gossip create a negative working environment.
By going to flextime, these negative busybodies have a much tougher job keeping up. Usually, they are not capable of it.
Well, if *IX isn't an OS, then none of IBM's Big Iron has ever had an OS. Ditto for for Univac, Burroughs, Cray, etc.
RAMBUS has gone for high frequencies: 800 MHz x 16bits = 1.6 GB/s peak. But 800 MHz isn't easy to design onto working PCBs. Tough enough on silicon dies, and mobo's had plenty of grief just getting to 100 MHz a few years ago. 800 is a big stepout.
Every trace has to be fully simulated, none of the usual cut'n'try. Can you say data-dependant crosstalk? Sure you can! Getting close to where you need to use wave-guide techniques.
The current slew rate (Amps/ns) to drive the traces is also proportionately higher, and it isn't easy to build such low ESR capacitance.
Just because you can run 100 MHz over 100m of clothesline (oops, I mean quality Cat5 cable) doesn't mean you can run 800 MHz over 10cm of traces. Balanced lines might help, but then you double the pincount.
Well, optimization is generally non-portable :)
But you ask a good question that deserves a serious answer: Yes, it should be possible to implement portable run-time cache blocking. Two parts: First the cache detection; second, break the code into variable sized blocks.
Portable cache detection isn't quick, but it is easy: Allocate a big hunk'o'RAM bigger than expected caches. Initialize it to get off the CoW zeropage. Time repeated (10 minimum) variable length rips. Start with 1KB so you will be on-scale with gettimeofday(). Step up by powers of two, keeping careful note of gettimeofday() results. There will be big steps when you cross cachesize boundaries. Even a simple programmed algorithm can find these. The whole process will cost at least one second, and perhaps 10.
The second part, variable sized blocks complicates the code considerably. You nest the base code inside a loop and that base code has a smaller dataspan plus an offset updated in the outerloop. Inner and outer loopcounts tuned to cachesize by automagic cache detection.
Erm
SoftUpdates is not a new filesystem. *BSD still uses the same FFS it always has. It's just a flag to modify OS behaviour.
Simplified, SoftUpdates is nothing more than ordered writes: Data hits the disk before metadata is altered. And lower level metadata is written before higher level. So when powerfail happens, there may be some unattached inodes, but chains are not broken. They just have old data.
Tux2 is a whole new "Phase Tree" filesystem. That means that both the FS proper and the tree algorithm have to be debugged in parallel. Fun!
IMHO, *BSD with it's "soft updates" by Kirk McKusick is far superior to Linux ext2 in crash fs corruption resistance. I deliberately hit the power-bar off switch during four FreeBSD 3.3 kernel SMP compiles fairly late in the process
(78 sec total vs 125 sec Linux 2.2.14) to make sure that data was going to disk.
In all four cases I ran, the fsck upon repowering was fast, minor and automatic, mostly freeing unattached blocks whose metadata presumably wasn't fully written at powerout. More surprising, in three of the four trials, `make -j 4` _resumed_ the compile and as best as I could tell completed the interrupted kernel compiles without error. (Same ksize. md5 doesn't work because of timestamp) About 30-45 seconds
worth of data was lost in dirty buffers at poweroff. In the fourth case, I got compile errors, but only had to `make clean`.
I am seriously impressed. I've had poweroffs during Linux kernel compiles and had manual fsck work to do. There some info at Kirks's site http://www.mckusick.com/softdep/index.html
and there's a very interesting paper whose URL I don't have handy.
Absolutely! This technique is called "cache blocking" -- break up data into cache-sized chunks and process a sub-frame then stitch subframes together. Not easy programming, but definitely worthwhile.
Much faster than any "natural order" long array ripping unless the processing is really minor in which case main RAM bandwidth rulez.
It's not the archive transfer that would necessarily violate copyright. The deal could include the hardware, and there would be no copyright violation.
But I'm presuming the buyer might want to make some money
Sure they can play gamers with non-Berne Convention countries. It won't save them from copyright violations.
I could demand royalties whenever they retrieve my posts for a paying customer. They're copying an publishing my work for their profit. If they or that customer are in the US or other BerneC country, I can probably "attach" that payment.
It's not FUNNY. My posts to USENET are in DejaNews. AFAIK, I still hold copyrights whether I marked them (Copyright 2000 ) or not. So does everyone else unless the copyrights in their country of posting don't give them copyright. Maybe even then, because US law does. IANAL.
There are exemptions under copyright for the intended transmission, and reduced damages because I don't mark my posts (C), but they're still copyright. If DejaNews or whomever buys them starts charging, I want a cut!
That said, other posters have commented on how an archive should be funded, and I agree it's a thorny issue. Much as I dislike gov't involvement, this seems a natural for the Library of Congress. Or maybe you would like an ICANN spinoff?
Seriously, how did this happen?
Are there too many external connections so that the peripheral space for pin connect is at a premium? IIRC the EV6 protocol needs 64 data pins, 48 address pins plus who knows how many control signals. Say 140 per device, of which there are at least 3-4 (CPU1, CPU2, RAM & AGP/PCI). 560 plus powers/grounds.
Yup, they could be short of pin pad peripheral space, and have free silicon. Note that they cannot just simply manufacture in bigger process because it won't be fast enough.
I love the Alpha processor, but it needs a shrink in the worst imaginable way:
A 0.35um 600 MHz 21264 sucks back 47A @ 2.35V = 109 W! The things desolder themselves (apocryphal). In 0.18um, 600 MHz would only be ~16A @ 1.6V = 26W leaving plenty of room to go up to the coveted GHz (26A@1.6=43W).
Is Compaq trying to kill this processor by denying it a shrink? Sorry, the font on that URL was too small to read.
You're missing Shannon's Theorum.
Information capacity of a channel is a function of it's Signal-to-Noise ratio. Higher S/N means you can encode more symbols per cycle. bits/Hz > 1. Modems above 2400 baud have been doing this for years. Gigabit ethernet over copper does this too.
Civil dicovery process is an awe-inspiring process. You get everything. But under the rules, are you allowed to publish what you find, or only that small portion that was admitted into evidence? What does your lawyer say?
You have made some incorrect assumptions. When I was much younger, I most certainly was taunted and subjected to verbal unpleantries. Also physical violence from my peers.
It was then that I discovered the stark difference between words and actions. Words can be ignored. Assault cannot. The impact words make is entirely up to your thinking processes. The impact punches have is a matter of physiology.
I'm afraid I respectfully disagree. I see little wrong with flaming, although I certainly won't indulge in the practice myself. Flamers reveal more about themselves than their targets.
While everybody might lose their temper every now and again, it isn't something to be proud of, nor does it win any points. USENET and the WWW should be read with large doses of skepticism.
I object to the term "verbal violence". That term should be reserved for credible threats of violence. Mere vitriol causes no harm other than hurt feelings. For those, I suggest growing a thicker skin, or getting some self-confidence.
Granted AOL/TW have denied 75%. But look at who does what, and is 75% unreasonable? It sure sounds usurious, but who provides what service?
If TW supplies all the hardware and the upstream connection, what is there left for the ISP to do but run POP, SMTP servers and maybe host some user webpages plus maybe answer a helpless desk? Then IMHO, 75% might be high but reasonable.
AFAIK, the biggest single cost for ISPs is their incoming lines and modem banks. Gone with cable. But if the ISPs still have to supply all the upstream bandwidth (routers in their shops), then 75% is ridiculous. Upstream bandwidth is the second biggest cost.
TW had better tread carefully here, or they will get themselves re-regulated.
Europe and Japan already have metering ... it's by the local phone company who charge for local phone calls by the minute. I've lived there, and it s#x. IMHO, it has caused slower I'net adoption and reduced usage.
Oh, I fully agree that Soft-Updates are not a panacea. They cannot recover from matadata corrupted by a powerfail in the middle of an inode write (assuming disks don't have hw PF logic not to start a write they cannot complete).
/usr (but not /home) as `noatime` to cut the metadata writes considerably.
But they greatly decrease the window of vulnerability from up to 15 seconds for sync down to approx 1 ms for an inode overwrite. Thats a very large and valuable reduction.
Orthogonally, you can mount / and
For similar crash protection, you might want to try out McKusick's "Soft Updates" that appear in *BSD systems. Essentially, they are ordered disk writes that makes sure data gets on the disk before metadata is altered. They go through the buffereing system, so performance isn't bad.
:( .
As an experiment, I pulled the plug towards the end of 5 FreeBSD kernel compiles (SMP `make -j 4`). In all cases, the fsck upon restart was minor, just freeing inodes. In four of the cases, `make` just picked up where it left off, and finished the kernel compile, losing only ~40 seconds work. In one case, a `make clean` had to be done because something was incomplete.
Don't try this on Linux! The ext2 fsck is horrible after a powerfail, and I've lost superblocks and had to re-install
Interesting. Very much as I thought. I guess the frustration is all-the-higher because at the time (1990) MS was the little guy and IBM was still Big Bad Blue.
So IBM really couldn't gain any support even though MS was in the wrong.
Well -- what goes around, comes around.
I do not believe the Luddites were factory workers. They were the country weavers who competed against the factories. Any assaulted factory worker of course is right to defend. But smashing machines in not defense -- it is offense.
Sadly, you are probably right about the state of human rights in England at that time. But it is singularly inappropriate for them to have directed their violence specifically for their own gain. They ceded the moral high ground.
Close, but no cigar. It's OK to fight in defense or against oppression by force. It's not OK to fight for financial advantage over others.
Fighting against taxation is OK because taxation is legalized theft/extortion backed by govenment use of force. You are just defending yourself against govt force. Fighting against mill owners is RONG because they have used NO physical force against you at all.
Simple, really. Even if you don't like it.
The weavers were trying to stop their competition by violence (invading and smashing factories). Pastorial window-dressing aside, I can understand why the weavers fought. I cannot understand why anyone else would take their side.
They were trying to force cloth customers to buy from them at higher prices rather than the spinning jenny factories.
Compliance with such uses of force is NEVER good for society as a whole.