Prioritizing ACKs doesn't reduce the lag time. It reduces the likelihood that TCP will overreact and reduce its sending rate due to perceived congestion.
Prioritizing ACKs may prevent drops but the main feature is essentially reducing lag time. TCP is self clocking, in that the sender can't send any more packets until it sees an ACK. If you get the ACKs out faster you'll get the replies faster. Thus prioritizing ACKs will make your downloads go faster. Since they are small packets this probably won't too adversely affect your upload bandwidth (may increase latency slightly).
This won't incorrectly set TCP's RTT timer because if anything you've shaved a few ms off your RTT. The new RTT may be less but it's not a lie.
The Unix manual is divided into sections. Section 1 is user commands, 2 is syscalls, 3 is library functions, 4-8 vary depending on the particular flavor. Some systems also have sections like 3f (fortran library functions).
Since some headings have entries in multiple sections (i.e. user commands with the same name as a library function) you disambiguate them by following them with their section number in parentheses. It has since become convention to say (for example) who(1) to indicate you are referring to the unix command (or its manpage) rather than some other random meaning of the word.
Actually I think there were some signals crossed here. The next GTA isn't late, it's just not scheduled out this FISCAL year (i.e. not before Oct. 31, end of Take Two's fiscal year). Nobody so far has claimed that it was ever scheduled to be released earlier.
Also Take Two had to write down charges related to Duke Nukem Forever (as mentioned in the article). Right now they're taking the whole development as a loss. That could mean that there's no game coming out ever, it could mean that it's just going to take so long they don't want to keep the expenses on their books, or it could just be that they're taking the charge in a good quarter when they can offset it against high profits.
Since they've already treated the devlopment costs of DNF as a loss they can treat the sales when (if) it comes out as pure profit. This is the kind of game that accountants play to keep earnings statments balanced. Like in physics, no money is created or destroyed but when you report what affects how the quarterly numbers look.
If fuel cell cars ever become popular...
on
10 Techno-Cool Cars
·
· Score: 2, Interesting
...Will Los Angeles have a humidity problem?
While not on the level of CO2, water vapor is a greenhouse gas. I also wonder if it might affect local climates.
I don't know how much water vapor fuel cell cars emit, or the environmental impact of refining hydrogen for them to use, but nothing comes for free.
(yes, yes, fuel cells are a vast improvement over burning gasoline.)
One problem with this is the performance will be crap using existing ethernet host adapters. There are a few companies working on host adapters with TCP-offload engines. Putting the TCP packets back together and pulling them apart takes a lot of kernel/system CPU cycles and it severely slows the data transmission rates.
It's not that the ethernet adapters will deliver bad performance, it's that they suck a lot of CPU cycles, so you need a faster CPU to get the same overall performance with iSCSI as you get with Fibre Channel. The SCSI market was in this same position years ago when SCSI cards were just dumb electrical interfaces and relied on the driver and host CPU to do the protocol work.
I think iSCSI might catch on faster than you think because there's a potential for cheap software only implementations on the low to medium end. A few hundred dollars buys a lot of mHz from Intel these days.
It's probably best to reserve judgement until we see what the performance is like for a tuned iSCSI software implementation. A network card that can offload the iSCSI protocol checksum combined with a zerocopy kernel driver might be able to deliver quite acceptible performance.
HTTP is restricted by browsers, many of which will not support files larger than a certain size. Furthermore, FTP allows for features such as resume, etc...
I don't think that any modern browser has file size restrictions. In HTTP 1.1 you can do resume, etc. I'm not aware of how you can do that in FTP but I'll take you at your word.
For very large files (say anything that takes longer than 1min to download) I would expect there's practically no difference between a good FTP server and a good HTTP server. For small files HTTP will win due to cheaper startup costs (no login).
I would use whichever you're more comfortable administering, which if you already have a website probably means HTTP.
More accurately you'll see SCSI RAID arrays with Ethernet ports. The technology will initially be too expensive to put on individual disks.
iSCSI is really targetted to replace (or augment) Fibre Channel (basically SCSI over fiber optics with 1-2 Gbit data rates). Fibre Channel is very expensive both for the interface cards and for the switches. iSCSI lets everyone leverage the developments of generic ethernet switches, routers, tunnels and bridges rather than having to develop new Fibre Channel ones from scratch.
As to your second question, You could potentially plug all of the disks (or arrays) into an ethernet switch and use them individually, but it's more likely you'd put some kind of front end in place to handle the filesystem tasks. Most filesystems assume they have sole ownership of the disks and can't share partitions between multiple live nodes. You would still gain the ability to partition big disks into smaller chunks per-compute node if you connected the disks directly (and maybe some failover capability) but that would probably be offset by the inability to share data.
I think that SGI's XFS filesystem can share partitions between multiple compute nodes but I don't know if that feature made it into the Linux port. For more info on this kind of thing google "clustered filesystems".
what is the use of a SCSI target disk formated as a NTFS volume shared through iSCSI to a Linux user ?
Well, since you asked: There's NTFS read support in the kernel which could make this a convenient way to share reference data between Windows and Linux boxes without having to deal with the complexity and vagarities of Samba.
Of course, this is bound to bring its own complexities and vagarities, but potentially somebody might use it.
A more likely target is an Oracle formatted disk shared by multiple clients potentially running many OSes. Oracle (and other commerical databases) have their own disk format in place of a filesystem and have already worked out the shared disk semantics to run over SANs.
iSCSI will be used in a SAN environment. This is only between computers and storage devices, and not betwen computers and the outside world. I think you're confusing SAN with LAN.
I doubt that's going to be the case for the very long term. iSCSI is going to be in the LAN space sooner or later. The protocol does give at least some thought to security, and you can run it over IPSec.
There are plenty of insecure protocols run on local LANs today that can be nearly as bad. I know that it's a bad idea to trust your LAN but nevertheless people do it all the time, especially in physically secure environments like machine rooms.
Not entirely. Apples chips cost more but do the same amount (or less, there's no MMX in an PowerPC). They are also more expensive per clock-cycle and embedded in a desktop (or server, if Apple made a server worthy of the name).
First of all, some PowerPCs have AltiVec, which is more-or-less MMX. In any case if you discount MMX-accelerated memcpy applications don't use MMX anyway. We'd probably be better off with a DMA engine (or maybe a DSP). Secondly, the quote is referring to the fact that PowerPCs get more computation done per clock-cycle than x86 (particularly Intel) CPUs. So you should be measuring $/MIPS or somesuch (Intel (or rather AMD) probably still wins though).
There are a lot of interesting trade-offs in processor design and lately Intel has been optimizing for cycle time rather than performance. Long term this is bound to fail in market segments that actually care about performance but what Intel knows (and what most of the world is just beginning to figure out) is that the vast majority of the PC market is no longer performance oriented. With modern graphics cards even cutting edge games aren't the CPU suckers they once were.
A good way to find good new authors (other than asking slashdot, which in this case seems to have been a great idea) is to find a reviewer you like. I'm particularly a fan of Dave Langford's reviews. He's very prolific, writes well, and knows the breadth of the field. He also writes a newsletter ansible as well as some quite amusing columns for various magazines.
Langford has introduced me to an sf culture of which previously I was only perhipherally aware.
by default shred overwrites the file 25 times. This is only the sort of thing you'd want to do with sensitive data, or just before tossing the harddrive (shred/dev/hda will shred the whole drive).
It reportedly takes about 20 minutes to shred a 1.44 mb floppy, though of course it can write at a faster rate on a hard drive.
There are other limitations to shred but if you do it to an entire disk before you toss it you can have a reasonable expecation of security.
It's not enough to write 0's to remove traces of a file. Writing random patterns is much better and for older drives you can even do better than random (i.e. more erasing in less passes). The shred(1) command from the GNU fileutils will take care of this for you in Unix-alikes.
But at the same time, is it really a success for all these so called inde developers to keep endlessly, endlessly, cloning the same handful of Tetris variants? Even ten years ago these things were stale, and now, in 2003, we have people hailing a design 100% borrowed from the Bust-A-Move arcade game from the mid 1990s as a "success" for the little developer?
Can you believe that in 2003 people are still playing blackjack, poker, bridge, hearts and spades? These games were old a hundred years ago.
There's nothing wrong with playing an old game. There's nothing wrong with updating an old game for a new platform, with a new twist on the rules, or even just a new look. Millions of people never played Bust-A-Move and can now enjoy Snood.
There's not really very many games out there, but that's okay. I'll still sign up for the next Wolfenstein 3D (Return to Unreal Team Capture the Half-Quake IV) or the next SimCity.
Note: I've read the linked article but not the actual paper.
I think the reason for doing a stippled technique is to cut down on preprocessing of the data set, rather than to speed the actual rendering of the graphics.
You're trying to visual a 3d volume, but you don't have a surface map. What you have is a series of bitmaps taken at different z-depths. You can either just render the z-ordered bitmaps with appropriate transparency (expensive for your graphics hardware) or you can try to calculate surfaces and render polygons. Calculating the surfaces can be extremely expensive (think hours of computer time on what was not too long ago a super-computer class machine).
It looks like what they've done is find a way to render the bitmap data with (a) minimal preprocessing and (b) not needing hundreds of megs of video RAM.
A few years ago I shared a VR setup with some people visualizng seismic data. They were always complaining about the onyx only having 256 megs of video ram...
HOWTO violate microsoft and apple patents
on
Font HOWTO For Linux
·
· Score: 5, Insightful
The flag that this article suggests turning on is off by default because the hinting algorithm in question may violate Microsoft and Apple patents. Not the average user really cares about this, but it was irresponsible of The Register to not explain this in the article. On the other hand, this is The Reg we're talking about here...
More info: http://freetype.sourceforge.net/patents.html
According to NPD Techworld, a research firm, PC game sales last year hit 65.3 million units, up 3.6 percent from the previous year. But 110 million console games were sold during the same period, and sales for the category rose 9 percent.
Actually, the WORST ending to a decent setup ever can be found in Stephenson's The Diamond Age. It may as well have ended in mid-sentence. That being said the beginning and middle are so compelling it may still be worth the read.
However, his books Zodiac ("The Eco-Thriller" -- it's not at all cyberpunk) and Cryptonomicon don't suffer from this problem at all. Both are excellent books.
I'd love to get the emacs integration, that'd be perfect. I'm glad to hear you're working on it. Do you expect that it'll appear on the perforce supplemental tools link or if not, where should I be looking for it once it's available?
When I finish (it's on the back burner at the moment as I'm busy with real work) I plan to submit it to the maintainer of p4.el, the p4-emacs integration package. If he doesn't want it I suppose I'll try to get it on the supplemental tools page.
Have you tried the p4pr program from Perforce's supplemental tools page? It does pretty much what you want, albeit slowly for our large (several million LOC) repository. It doesn't have support in the p4-emacs integration yet but
I'm working on some.
Slashdot Mirror
Well, maybe they are, but that's not what's reported in the article.
AOL users are reporting 5.5 million spam messages a day to customer service.
Prioritizing ACKs doesn't reduce the lag time. It reduces the likelihood that TCP will overreact and reduce its sending rate due to perceived congestion.
Prioritizing ACKs may prevent drops but the main feature is essentially reducing lag time. TCP is self clocking, in that the sender can't send any more packets until it sees an ACK. If you get the ACKs out faster you'll get the replies faster. Thus prioritizing ACKs will make your downloads go faster. Since they are small packets this probably won't too adversely affect your upload bandwidth (may increase latency slightly).
This won't incorrectly set TCP's RTT timer because if anything you've shaved a few ms off your RTT. The new RTT may be less but it's not a lie.
The bumper sticker description of this project is 'see first, understand first, act first and finish decisively,'
That's one freakin' long bumper sticker.
The Unix manual is divided into sections. Section 1 is user commands, 2 is syscalls, 3 is library functions, 4-8 vary depending on the particular flavor. Some systems also have sections like 3f (fortran library functions).
Since some headings have entries in multiple sections (i.e. user commands with the same name as a library function) you disambiguate them by following them with their section number in parentheses. It has since become convention to say (for example) who(1) to indicate you are referring to the unix command (or its manpage) rather than some other random meaning of the word.
Actually I think there were some signals crossed here. The next GTA isn't late, it's just not scheduled out this FISCAL year (i.e. not before Oct. 31, end of Take Two's fiscal year). Nobody so far has claimed that it was ever scheduled to be released earlier.
Also Take Two had to write down charges related to Duke Nukem Forever (as mentioned in the article). Right now they're taking the whole development as a loss. That could mean that there's no game coming out ever, it could mean that it's just going to take so long they don't want to keep the expenses on their books, or it could just be that they're taking the charge in a good quarter when they can offset it against high profits.
Since they've already treated the devlopment costs of DNF as a loss they can treat the sales when (if) it comes out as pure profit. This is the kind of game that accountants play to keep earnings statments balanced. Like in physics, no money is created or destroyed but when you report what affects how the quarterly numbers look.
...Will Los Angeles have a humidity problem?
While not on the level of CO2, water vapor is a greenhouse gas. I also wonder if it might affect local climates.
I don't know how much water vapor fuel cell cars emit, or the environmental impact of refining hydrogen for them to use, but nothing comes for free.
(yes, yes, fuel cells are a vast improvement over burning gasoline.)
It's not that the ethernet adapters will deliver bad performance, it's that they suck a lot of CPU cycles, so you need a faster CPU to get the same overall performance with iSCSI as you get with Fibre Channel. The SCSI market was in this same position years ago when SCSI cards were just dumb electrical interfaces and relied on the driver and host CPU to do the protocol work.
I think iSCSI might catch on faster than you think because there's a potential for cheap software only implementations on the low to medium end. A few hundred dollars buys a lot of mHz from Intel these days.
It's probably best to reserve judgement until we see what the performance is like for a tuned iSCSI software implementation. A network card that can offload the iSCSI protocol checksum combined with a zerocopy kernel driver might be able to deliver quite acceptible performance.
I don't think that any modern browser has file size restrictions. In HTTP 1.1 you can do resume, etc. I'm not aware of how you can do that in FTP but I'll take you at your word.
For very large files (say anything that takes longer than 1min to download) I would expect there's practically no difference between a good FTP server and a good HTTP server. For small files HTTP will win due to cheaper startup costs (no login).
I would use whichever you're more comfortable administering, which if you already have a website probably means HTTP.
More accurately you'll see SCSI RAID arrays with Ethernet ports. The technology will initially be too expensive to put on individual disks.
iSCSI is really targetted to replace (or augment) Fibre Channel (basically SCSI over fiber optics with 1-2 Gbit data rates). Fibre Channel is very expensive both for the interface cards and for the switches. iSCSI lets everyone leverage the developments of generic ethernet switches, routers, tunnels and bridges rather than having to develop new Fibre Channel ones from scratch.
As to your second question, You could potentially plug all of the disks (or arrays) into an ethernet switch and use them individually, but it's more likely you'd put some kind of front end in place to handle the filesystem tasks. Most filesystems assume they have sole ownership of the disks and can't share partitions between multiple live nodes. You would still gain the ability to partition big disks into smaller chunks per-compute node if you connected the disks directly (and maybe some failover capability) but that would probably be offset by the inability to share data.
I think that SGI's XFS filesystem can share partitions between multiple compute nodes but I don't know if that feature made it into the Linux port. For more info on this kind of thing google "clustered filesystems".
Well, since you asked: There's NTFS read support in the kernel which could make this a convenient way to share reference data between Windows and Linux boxes without having to deal with the complexity and vagarities of Samba.
Of course, this is bound to bring its own complexities and vagarities, but potentially somebody might use it.
A more likely target is an Oracle formatted disk shared by multiple clients potentially running many OSes. Oracle (and other commerical databases) have their own disk format in place of a filesystem and have already worked out the shared disk semantics to run over SANs.
I doubt that's going to be the case for the very long term. iSCSI is going to be in the LAN space sooner or later. The protocol does give at least some thought to security, and you can run it over IPSec.
There are plenty of insecure protocols run on local LANs today that can be nearly as bad. I know that it's a bad idea to trust your LAN but nevertheless people do it all the time, especially in physically secure environments like machine rooms.
First of all, some PowerPCs have AltiVec, which is more-or-less MMX. In any case if you discount MMX-accelerated memcpy applications don't use MMX anyway. We'd probably be better off with a DMA engine (or maybe a DSP). Secondly, the quote is referring to the fact that PowerPCs get more computation done per clock-cycle than x86 (particularly Intel) CPUs. So you should be measuring $/MIPS or somesuch (Intel (or rather AMD) probably still wins though).
There are a lot of interesting trade-offs in processor design and lately Intel has been optimizing for cycle time rather than performance. Long term this is bound to fail in market segments that actually care about performance but what Intel knows (and what most of the world is just beginning to figure out) is that the vast majority of the PC market is no longer performance oriented. With modern graphics cards even cutting edge games aren't the CPU suckers they once were.
...is a Beowulf cluster of PVRs?
sorry, but it had to be said.
A good way to find good new authors (other than asking slashdot, which in this case seems to have been a great idea) is to find a reviewer you like. I'm particularly a fan of Dave Langford's reviews. He's very prolific, writes well, and knows the breadth of the field. He also writes a newsletter ansible as well as some quite amusing columns for various magazines.
Langford has introduced me to an sf culture of which previously I was only perhipherally aware.
by default shred overwrites the file 25 times. This is only the sort of thing you'd want to do with sensitive data, or just before tossing the harddrive (shred /dev/hda will shred the whole drive).
It reportedly takes about 20 minutes to shred a 1.44 mb floppy, though of course it can write at a faster rate on a hard drive.
There are other limitations to shred but if you do it to an entire disk before you toss it you can have a reasonable expecation of security.
(btw a better link to the shred documentation)
It's not enough to write 0's to remove traces of a file. Writing random patterns is much better and for older drives you can even do better than random (i.e. more erasing in less passes). The shred(1) command from the GNU fileutils will take care of this for you in Unix-alikes.
e s/ shred/1
_ del.html for an informative paper about the details of how secure deletion works.
http://btr0xw.rz.uni-bayreuth.de/cgi-bin/manpag
See also http://www.cs.auckland.ac.nz/~pgut001/pubs/secure
Can you believe that in 2003 people are still playing blackjack, poker, bridge, hearts and spades? These games were old a hundred years ago.
There's nothing wrong with playing an old game. There's nothing wrong with updating an old game for a new platform, with a new twist on the rules, or even just a new look. Millions of people never played Bust-A-Move and can now enjoy Snood.
There's not really very many games out there, but that's okay. I'll still sign up for the next Wolfenstein 3D (Return to Unreal Team Capture the Half-Quake IV) or the next SimCity.
Note: I've read the linked article but not the actual paper.
I think the reason for doing a stippled technique is to cut down on preprocessing of the data set, rather than to speed the actual rendering of the graphics.
You're trying to visual a 3d volume, but you don't have a surface map. What you have is a series of bitmaps taken at different z-depths. You can either just render the z-ordered bitmaps with appropriate transparency (expensive for your graphics hardware) or you can try to calculate surfaces and render polygons. Calculating the surfaces can be extremely expensive (think hours of computer time on what was not too long ago a super-computer class machine).
It looks like what they've done is find a way to render the bitmap data with (a) minimal preprocessing and (b) not needing hundreds of megs of video RAM.
A few years ago I shared a VR setup with some people visualizng seismic data. They were always complaining about the onyx only having 256 megs of video ram...
The flag that this article suggests turning on is off by default because the hinting algorithm in question may violate Microsoft and Apple patents. Not the average user really cares about this, but it was irresponsible of The Register to not explain this in the article. On the other hand, this is The Reg we're talking about here...
More info: http://freetype.sourceforge.net/patents.html
Nope. Recent processors cache physical memory so
you don't flush the cache on a context switch.
Read the fine print. the comparison is PC to console software sales markets, not pc to total combined market.
Ah, quite right. My mistake.
That's 37.2%, not 59.4%, moron.
Actually, the WORST ending to a decent setup ever can be found in Stephenson's The Diamond Age. It may as well have ended in mid-sentence. That being said the beginning and middle are so compelling it may still be worth the read. However, his books Zodiac ("The Eco-Thriller" -- it's not at all cyberpunk) and Cryptonomicon don't suffer from this problem at all. Both are excellent books.
When I finish (it's on the back burner at the moment as I'm busy with real work) I plan to submit it to the maintainer of p4.el, the p4-emacs integration package. If he doesn't want it I suppose I'll try to get it on the supplemental tools page.
The feature of CVS I miss dearly is annotate
Have you tried the p4pr program from Perforce's supplemental tools page? It does pretty much what you want, albeit slowly for our large (several million LOC) repository. It doesn't have support in the p4-emacs integration yet but I'm working on some.