The difference in the UK I believe is that the actual bandwidth is being carried on fibreoptic that is strung on the same towers rather than down the actual transmission lines. So they are capitalizing on the real-estate value of the point-to-point corridors that the network of transmission towers creates. Frankly that makes a lot of sense to me. I don;t know the numbers for the UK, but the US has I suspect far more 'dark' (unusde) fibre already in the ground and hence there is probably less demand for long-haul datapipes, the problem being the classic of last mile distribution instead.
Well, just concentrating on the purely technical aspects of size. Smaller is better because it implies shorter signal run which can then be faster, lower power and emit less radiation (radio noise). As for the shape...well a single board should always be more space efficient and cheaper because of the absence of interboard connectors, however when it is desirable to have a sensitive analog style componants mixed with noisy microprocessor style componants moving them to different boards can really simplfy things. Also if the board with the CPU needs many signal layers but the others only a few then that can change the cost equation.
Governments (especially the US) have made an art out of screwing many capable people whos detailed antarctic plans have hit some unlikely snag, despite there best intent. It is likely this guy arranged nothing in advance with McMurdo frankly because he knew by reputation what there response would be. Adventure Network International fly planes into antartica for climbing expeditions and they have been fighting against these attitudes since day 1. They have to bring in everything themselves including return trip fuel. They normally refuel at a BAS base where they have shipped fuel to in advance. Check out the history of Giles Kershaw if you want evidence that even the very best antarctic pilot faces random chances and poor odds. At least this guy hasn;t been forcably 'rescued' so far against his will, that has been the fate of some of his predecessors.
For what its worth by philosophy for many years has been for my SLR needs I buy old Canon A-1 and AE-1 stuff (we are talking 20 to 30 year old equipment here). It was bomb proof metal construction, and the fixed focal lenth lenses were very good quality, and on the odd occasion I loose or destroy one, I'm not horibly out of pocket.
Sounds like this poster would be advised to attend this CS class because he seems to have learned all his chip design skills from reading Wired or other bullshit. 300KGates is more than enough to implement any number of complete applications, and to boot many of them which wouldn't have a hope in hell of running on any '2GHz processor' you care to name. All those linux design wins which plaster the pages of/.'s editions typically don't run on chips even as powerful as the one this article is about. An 8051 could be realized in 10 to 20K gates without any major sweat and regularly is, in fact its possibly the most popular embeded CPU used in ASIC design at the moment (in terms of different design starts). Mind you, and this comment is very applicable to OpenRISC with which I am intimately familiar, its a LONG way from making a 300Kgate FPGA that can be demonstrated (or and ASIC for that matter) to making an ASIC that is fully verified and production test worthy. This will be the challenge going forward for open hardware, how enthusiastic amateurs can gain the experience needed to complement the symantics of an RTL design language if the resultant ardware is to be truely product worthy.
I AM using this processor in a commercial product. I have to be sincere about this, its tremendous value for money(!) and its reasonably bug free, but the architecture and code quality are about a 3 out of 10 against its peers in the embeded world. So saying that both LEON and OpenRISC have indeed brought some momentum to the space of free (as in the Stallman definition) hardware and for that alone if nothing else we should all be pleased.
Number portability is absolutely essential if customers really want to do something about crappy US cell coverage. Whining does nothing, the status quo proves that, however changing carrier really gets a cell companies attention. The process of people swaping cell phone service is called 'churn' in the buisness and it is very expensive for the cell phone companies, thus they want to stop it at any cost. Thus you change carrier and tell them it because your phone is unreliable in your home area, and hey! they get motivated to find a way to fix it. I understand peoples frustration with contracts, however what you have to realise is that they also are going away, the rest of the world has number portability and a majority of customers are contract free paying either monthly or against pre-paid credit and own there own unlocked phones
...then they would not say things like "It has 192MB of memory" then later "It has 128MB of memory dedicted for multimedia, making a total of 196MB memory"
What might interest geeks more than another lack luster attempt to sell POTS videophones instead of someone marketing an inovative broadband embeded solution, is that Vialta is a thinly disguised arm of ESS technologies, and the power behind the phone is non other than the DVD processor behind the APEX DVD players that all region code phobic hackers love and cherish. So that said what could you do these puppies that might actually be interesting! DIVX decoder anyone?
I seem to have read in more than one place recently that empirical evidence suggests that linking to your site, especially from other highly linked/ranked sites is a major factor in Googles ranking for search results. Thus if people actually respect these sites wish's they will eliminate themsleves from the HTTP gene pool.....
I had the following international "Shipping" incident with UPS. I'm a chip designer and was working for Motorola in Holland at the time. However I was posted on assignment at a vendors site in Seatle working on some new design software. We designed a new chip with this vendors software and it did some bizarre stuff. Since it was a prototype before production we didn't make many of them, and I had them shipped from Holland to Seattle UPS air. They were in a plastic chip packing rack, an indistructable gizmo that locks them rigidly inplace, aout 12"x6"x0.5" that we just put into the standard UPS plastic shipping envelope. When this arrived in Seattle the UPS guy gave the envelope to the front desk girl who signed then called me. Snag was he only delivered an empty envelope. There was a long cut the full length of the envelope, and only air inside. They never did find the chips, and insurance was not an issue since no money could buy us the 8 weeks it took us to make new chips. I've never used UPS since, Fedex gets all by couier buisness and has never even vaguely fucked up anything.
ION
The point most people miss about chip design in general is that whatever the methodology being discussed, modern chip designs would be utterly infeasable without the CAD software that goes with them. The complexity of any IC design both synchronous or asynchronous is utterly beyond any manual design methods at this point, and the main reason that synchronous design predominates today is that CAD tools for synchronous synthesis came to market (Synopsys in particular ) and have dominated the field for nearly 10 years now. However research on async CAD tools continues, one notable effort being the European OMI project EXACT (http://www.omimo.be/system/templates/OMIProjects_ Detail.cfm?ID=6&Project=6143) which yielded a commercial error correction chip used by Philips in DCC players. If groups such as the AMULET group can automate there methodolgies then async design can quickly gain ground in various power and performance sensitive niches.
Seems like enough people are interested that its worth my time writing a little helper on IP phones here. Standards: There are 3 standards in the play at the moment that are IP Phone candidates. H.323 which is the incumbent mature protocol in IP video conferencing and also the underlying protocol of MS netmeeting is the one that these phones and others will be addressing first. H.323 is somewhat ungainly based on a binary protocol thats a bitch to debug and firewall unfreindly. MGCP which is the basis for forthcoming IP telephony in the digital cable TV system, and a much easier protocol to understand being text based. And lastly SIP which is the new darling of the IP telephony world and already supported in beta versions of Cisco IOS. The actual cisco phones do NOT talk any of these standards, but insted talk something nicknamed the "skinny stack" which cisco inherited from Selisius. Other Cisco equipemnt in the network translates to the'standard protocols'. Expect to see many more IP phones from other companies in the next few months, cisco is not the only show in town. Interoperability: Until someone has a brainwave the user interface to make calls on all these phones is going to be a classic phone number which will be tarnslated into IP andthen ethernet by protocol engines transparant to the user. IP Phones interoperate with the legacy phone network through 'Gateways', just as present TollBypass cheap IP long distance works right now. You can expect that LDAP will be integrated in to buisness style deployments of these phones pretty quickly so throw that phone list away! Bandwidth: An IP phone will use anything from around 80kbit/S (G.711 audio) to maybe 24kbit/S (G.729/G.723), but in actual fact the killer problem is latency and jitter, so expect to need to use new protocols to make them work well. Cisco and others will use a standard called 802.3p which basicly adds a priority into the ethernet framing info so that switchs can expedite the delivery and routers can tranlsatethis into other protocols for delivery over the WAN (Diff-Serv is the ideal here). Enough I'm Boring myself! ION
This is only part of the solution, it costs more!
on
Cheap Gigabit Ether
·
· Score: 1
This is misleading, this chip is only a PHY (physical interface) and needs another chip called a MAC (Media access controller) to function as a NIC. It would also need transformers for electrical isolation and the RJ45 and PCB, probably a whole bunch more little stuff as well. Just for comparison a 100/10Mb PHY is about $5 in volume right now (probably less) and most solutions for 100/10 are now integrated into a single chip that sells for less than $10. We are a LONG way from gigabit at home!
The term 10/100 hub is misleading Products like this are really 2 hubs and a 2 port switch. All 10Mb devices run on one hub and 100Mb ones on the other hub and the switch bridges between them. Thus collisions on any 10Mb port are seen by other 10Mb devices and collisions between 100Mb devices are seen by other100Mb devices. The rate conversion from 100->10 is a royal pain because if you want to do it well you need a lot of RAM built into the switch. If you buy some cheap equipment you will notice that 100/10 peformance can be terrible because the switch causes 100Mb collisions to do primitive flow control, affecting all connected 100MB devices. For 1000Mb hubs are obselete I'd think, pure switching architectures are the only way to go.
Some good posts already about the much cheaper price of music racks on the web. There is a good on-line site to browse this stuff at: http://www.sweetwater.com/equip-dir/cases/
I actually like some of the portable plastic molded cases which are rock solid and great if you ship your computers a lot. The main issue Ive come across however with most rackmount cases is there depth, which can be huge (like 3 feet!).
So who cares to calculate what a Transmeta processor running on vodka will have for battery life? Seems like a weeks battery life should be feasable to me. (providing I dont get thirsty....)
Whilst there are many historical reasons that undoubtedly contribute to this including the fragmentation of effort of open/free BSD etc.... and the original BSD licensing issues, I can't help wondering if there is a key role played by the association of BSD with a physical entity namely Berkley rather with a global comunity of "no fixed abode". Maybe people psychologicaly don't feel an equal part of this thing, but more like they are helping with someone elses project.
My spin on the desire for Hard Real Time is that many cuurent RT systems need Hard time goals but the underlying "Real Time" OS is anything but and hence the only solution is to throw excess performance at the problem to ensure all things (including non-critical stuff) complete in a timely way. Hard RT should allow leaner hardware to do the same job.
The Silicon Valley Company I work for has provided the following little perks in the 4 years I've been here: Weekend Ski-trip to Lake Tahoe White Water Rafting Trip Boat Cruise on San Francisco Bay ...this in addition to pretty much all those other standard perks, it certainly helps to numb the pain of writting the monthly rent check.
Here are 2 benchmarks I've had to do recently. They aren't a complete test of NFS performance by any means but illustrate that a Network Appliance (F720) can match local disk performance and trounce a SUN at NFS server performance. I would add that though I use linux as an NFS server at home for my 4 machine network with few problems, my empirical experience is that it is not ready for high-load mision critical NFS server applications. My opinion is that a Network Appliance's clever write caching technology reduces the NFSv2 write penalty dramtically and increases linux client useability. We run 100+ fast linux clients and 20+Suns and I know that this setup is best server ($$$ and performance) by a Netapp rather than ANY UNIX solution.
This first one shows raw sustained NFS performance by using dd to read or write a 100MByte file over a switched full duplex 100MBit ethernet between a P-II 333 (3COM 905) and Redhat 5.2 and a NetApp720. In summary I can achieve approximately: 33Mbits/sec NFS write performance to the network appliance and 62MBits/sec NFS read performance from the network appliance.
XXX.8x8.com 28: time dd if=/dev/zero of=/mnt/ianb/testfile bs=16k count=6250 6250+0 records in 6250+0 records out 0.050u 3.740s 0:25.24 15.0% 0+0k 0+0io 96pf+0w XXX.8x8.com 29: time dd if=/dev/zero of=/mnt/ianb/testfile bs=16k count=6250 6250+0 records in 6250+0 records out 0.040u 3.840s 0:23.13 16.7% 0+0k 0+0io 95pf+0w XXX.8x8.com 30: time dd if=/mnt/ianb/testfile of=/dev/null bs=16k 6250+0 records in 6250+0 records out 0.040u 2.690s 0:14.60 18.6% 0+0k 0+0io 99pf+0w XXX.8x8.com 31: time dd if=/mnt/ianb/testfile of=/dev/null bs=16k 6250+0 records in 6250+0 records out 0.030u 3.150s 0:12.58 25.2% 0+0k 0+0io 114pf+0w XXX.8x8.com 32: ls -al/mnt/ianb/testfile -rw-r--r-- 1 ianb users 102400000 Mar 11 10:29 /mnt/ianb/testfile
This 2nd benchmark is a GCC compilation of 8000 lines of C in many files. It illustrates both the dramtic differences between local disk/netappNFS/solarisNFS and the benefits of using gcc and make options to improve efficiency by running parallel compiles (which uses idle CPU that is lost whilst the OS waits for the remote RPC's to complete in an unparallelized compile) and by using interprocess comuncation insted of files in /tmp to communicate between different compile stages. Conclusion using 100Mbit network, compile performance approaches local disk performance.
NADS BUILD (GCC) ON SUN NFS DISK (10Mb/s net) 6.480u 1.460s 0:38.36 20.6% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (100Mb/s net) 6.480u 1.110s 0:29.69 25.5% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (10Mb/s net) WITH GCC -PIPE (NO/tmp files) AND MAKE -j 5 6.890u 1.770s 0:33.17 26.1% 0+0k 0+0io 12597pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (100Mb/s net) WITH GCC -PIPE (NO/tmp files) AND MAKE -j 5 6.660u 1.280s 0:25.22 31.4% 0+0k 0+0io 11736pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (10Mb/s net) 6.650u 1.230s 0:17.67 44.5% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (100Mb/s net) 6.490u 1.250s 0:09.35 82.7% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (10Mb/s net) WITH GCC -PIPE (NO/tmp files) AND MAKE -j 5 6.940u 1.430s 0:13.93 60.0% 0+0k 0+0io 11741pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (100Mb/s net) WITH GCC -PIPE (NO/tmp files) AND MAKE -j 5 6.830u 1.140s 0:08.77 90.8% 0+0k 0+0io 11736pf+0w
NADS BUILD (GCC) ON LOCAL DISK 5.730u 1.020s 0:11.31 59.6% 0+0k 0+0io 11069pf+0w
NADS BUILD (GCC) ON LOCAL DISK WITH GCC -PIPE (NO/tmp files) 5.700u 1.040s 0:09.71 69.4% 0+0k 0+0io 10271pf+0w
NADS BUILD (GCC) ON LOCAL DISK WITH GCC -PIPE (NO/tmp files) AND MAKE -j 5 6.000u 1.100s 0:08.19 86.6% 0+0k 0+0io 10280pf+0w
Slashdot Mirror
The difference in the UK I believe is that the actual bandwidth is being carried on fibreoptic that is strung on the same towers rather than down the actual transmission lines. So they are capitalizing on the real-estate value of the point-to-point corridors that the network of transmission towers creates. Frankly that makes a lot of sense to me. I don;t know the numbers for the UK, but the US has I suspect far more 'dark' (unusde) fibre already in the ground and hence there is probably less demand for long-haul datapipes, the problem being the classic of last mile distribution instead.
Well, just concentrating on the purely technical aspects of size. Smaller is better because it implies shorter signal run which can then be faster, lower power and emit less radiation (radio noise).
As for the shape...well a single board should always be more space efficient and cheaper because of the absence of interboard connectors, however when it is desirable to have a sensitive analog style componants mixed with noisy microprocessor style componants moving them to different boards can really simplfy things. Also if the board with the CPU needs many signal layers but the others only a few then that can change the cost equation.
Governments (especially the US) have made an art out of screwing many capable people whos detailed antarctic plans have hit some unlikely snag, despite there best intent. It is likely this guy arranged nothing in advance with McMurdo frankly because he knew by reputation what there response would be. Adventure Network International fly planes into antartica for climbing expeditions and they have been fighting against these attitudes since day 1. They have to bring in everything themselves including return trip fuel. They normally refuel at a BAS base where they have shipped fuel to in advance. Check out the history of Giles Kershaw if you want evidence that even the very best antarctic pilot faces random chances and poor odds.
At least this guy hasn;t been forcably 'rescued' so far against his will, that has been the fate of some of his predecessors.
For what its worth by philosophy for many years has been for my SLR needs I buy old Canon A-1 and
AE-1 stuff (we are talking 20 to 30 year old equipment here). It was bomb proof metal construction, and the fixed focal lenth lenses were very good quality, and on the odd occasion I loose or destroy one, I'm not horibly out of pocket.
Sounds like this poster would be advised to attend this CS class because he seems to have learned all his chip design skills from reading Wired or other bullshit. 300KGates is more than enough to implement any number of complete applications, and to boot many of them which wouldn't have a hope in hell of running on any '2GHz processor' you care to name. All those linux design wins which plaster the pages of /.'s editions typically don't run on chips even as powerful as the one this article is about. An 8051 could be realized in 10 to 20K gates without any major sweat and regularly is, in fact its possibly the most popular embeded CPU used in ASIC design at the moment (in terms of different design starts). Mind you, and this comment is very applicable to OpenRISC with which I am intimately familiar, its a LONG way from making a 300Kgate FPGA that can be demonstrated (or and ASIC for that matter) to making an ASIC that is fully verified and production test worthy. This will be the challenge going forward for open hardware, how enthusiastic amateurs can gain the experience needed to complement the symantics of an RTL design language if the resultant ardware is to be truely product worthy.
I AM using this processor in a commercial product. I have to be sincere about this, its tremendous value for money(!) and its reasonably bug free, but the architecture and code quality are about a 3 out of 10 against its peers in the embeded world. So saying that both LEON and OpenRISC have indeed brought some momentum to the space of free (as in the Stallman definition) hardware and for that alone if nothing else we should all be pleased.
Wattage on the other hands has a direct effect on the elctricty bill of the church....15KWatts of power amp eh?? I wonder which is cheaper to run?
Number portability is absolutely essential if customers really want to do something about crappy US cell coverage. Whining does nothing, the status quo proves that, however changing carrier really gets a cell companies attention. The process of people swaping cell phone service is called 'churn' in the buisness and it is very expensive for the cell phone companies, thus they want to stop it at any cost. Thus you change carrier and tell them it because your phone is unreliable in your home area, and hey! they get motivated to find a way to fix it. I understand peoples frustration with contracts, however what you have to realise is that they also are going away, the rest of the world has number portability and a majority of customers are contract free paying either monthly or against pre-paid credit and own there own unlocked phones
...then they would not say things like
"It has 192MB of memory" then later
"It has 128MB of memory dedicted for multimedia,
making a total of 196MB memory"
Sigh.......
What might interest geeks more than another lack luster attempt to sell POTS videophones instead of someone marketing an inovative broadband embeded solution, is that Vialta is a thinly disguised arm of ESS technologies, and the power behind the phone is non other than the DVD processor behind the APEX DVD players that all region code phobic hackers love and cherish. So that said what could you do these puppies that might actually be interesting! DIVX decoder anyone?
I seem to have read in more than one place recently that empirical evidence suggests that linking to your site, especially from other highly linked/ranked sites is a major factor in Googles ranking for search results. Thus if people actually respect these sites wish's they will eliminate themsleves from the HTTP gene pool.....
I had the following international "Shipping" incident with UPS. I'm a chip designer and was working for Motorola in Holland at the time. However I was posted on assignment at a vendors site in Seatle working on some new design software. We designed a new chip with this vendors software and it did some bizarre stuff. Since it was a prototype before production we didn't make many of them, and I had them shipped from Holland to Seattle UPS air. They were in a plastic chip packing rack, an indistructable gizmo that locks them rigidly inplace, aout 12"x6"x0.5" that we just put into the standard UPS plastic shipping envelope. When this arrived in Seattle the UPS guy gave the envelope to the front desk girl who signed then called me. Snag was he only delivered an empty envelope. There was a long cut the full length of the envelope, and only air inside. They never did find the chips, and insurance was not an issue since no money could buy us the 8 weeks it took us to make new chips. I've never used UPS since, Fedex gets all by couier buisness and has never even vaguely fucked up anything.
ION
The point most people miss about chip design in general is that whatever the methodology being discussed, modern chip designs would be utterly infeasable without the CAD software that goes with them. The complexity of any IC design both synchronous or asynchronous is utterly beyond any manual design methods at this point, and the main reason that synchronous design predominates today is that CAD tools for synchronous synthesis came to market (Synopsys in particular ) and have dominated the field for nearly 10 years now. However research on async CAD tools continues, one notable effort being the European OMI project EXACT (http://www.omimo.be/system/templates/OMIProjects_ Detail.cfm?ID=6&Project=6143) which yielded a commercial error correction chip used by Philips in DCC players. If groups such as the AMULET group can automate there methodolgies then async design can quickly gain ground in various power and performance sensitive niches.
Why stop at 100Mb when you can pump full blown
1000base ethernet down that fibre......
www.worldwidepackets.com
Seems like enough people are interested that its worth my time writing a little helper on IP phones here. Standards: There are 3 standards in the play at the moment that are IP Phone candidates. H.323 which is the incumbent mature protocol in IP video conferencing and also the underlying protocol of MS netmeeting is the one that these phones and others will be addressing first. H.323 is somewhat ungainly based on a binary protocol thats a bitch to debug and firewall unfreindly. MGCP which is the basis for forthcoming IP telephony in the digital cable TV system, and a much easier protocol to understand being text based. And lastly SIP which is the new darling of the IP telephony world and already supported in beta versions of Cisco IOS. The actual cisco phones do NOT talk any of these standards, but insted talk something nicknamed the "skinny stack" which cisco inherited from Selisius. Other Cisco equipemnt in the network translates to the'standard protocols'. Expect to see many more IP phones from other companies in the next few months, cisco is not the only show in town. Interoperability: Until someone has a brainwave the user interface to make calls on all these phones is going to be a classic phone number which will be tarnslated into IP andthen ethernet by protocol engines transparant to the user. IP Phones interoperate with the legacy phone network through 'Gateways', just as present TollBypass cheap IP long distance works right now. You can expect that LDAP will be integrated in to buisness style deployments of these phones pretty quickly so throw that phone list away! Bandwidth: An IP phone will use anything from around 80kbit/S (G.711 audio) to maybe 24kbit/S (G.729/G.723), but in actual fact the killer problem is latency and jitter, so expect to need to use new protocols to make them work well. Cisco and others will use a standard called 802.3p which basicly adds a priority into the ethernet framing info so that switchs can expedite the delivery and routers can tranlsatethis into other protocols for delivery over the WAN (Diff-Serv is the ideal here). Enough I'm Boring myself! ION
This is misleading, this chip is only a PHY (physical interface) and needs another chip called a MAC (Media access controller) to function as a NIC. It would also need transformers for electrical isolation and the RJ45 and PCB, probably a whole bunch more little stuff as well. Just for comparison a 100/10Mb PHY is about $5 in volume right now (probably less) and most solutions for 100/10 are now integrated into a single chip that sells for less than $10. We are a LONG way from gigabit at home!
The term 10/100 hub is misleading Products like this are really 2 hubs and a 2 port switch. All 10Mb devices run on one hub and 100Mb ones on the other hub and the switch bridges between them. Thus collisions on any 10Mb port are seen by other 10Mb devices and collisions between 100Mb devices are seen by other100Mb devices. The rate conversion from 100->10 is a royal pain because if you want to do it well you need a lot of RAM built into the switch. If you buy some cheap equipment you will notice that 100/10 peformance can be terrible because the switch causes 100Mb collisions to do primitive flow control, affecting all connected 100MB devices. For 1000Mb hubs are obselete I'd think, pure switching architectures are the only way to go.
Some good posts already about the much cheaper
price of music racks on the web. There is a
good on-line site to browse this stuff at:
http://www.sweetwater.com/equip-dir/cases/
I actually like some of the portable plastic molded
cases which are rock solid and great if you ship your
computers a lot. The main issue Ive come across however
with most rackmount cases is there depth, which can be
huge (like 3 feet!).
ION
So who cares to calculate what a Transmeta processor running on vodka will have for battery
life? Seems like a weeks battery life should be feasable to me. (providing I dont get thirsty....)
ION
Whilst there are many historical reasons that
undoubtedly contribute to this including the
fragmentation of effort of open/free BSD etc....
and the original BSD licensing issues, I can't
help wondering if there is a key role played by
the association of BSD with a physical entity
namely Berkley rather with a global comunity of
"no fixed abode". Maybe people psychologicaly
don't feel an equal part of this thing, but more
like they are helping with someone elses project.
My spin on the desire for Hard Real Time is that many cuurent RT systems need Hard time goals but the underlying "Real Time" OS is anything but and hence the only solution is to throw excess performance at the problem to ensure all things (including non-critical stuff) complete in a timely way. Hard RT should allow leaner hardware to do the same job.
The Silicon Valley Company I work for has provided
the following little perks in the 4 years I've
been here:
Weekend Ski-trip to Lake Tahoe
White Water Rafting Trip
Boat Cruise on San Francisco Bay
...this in addition to pretty much all those
other standard perks, it certainly helps to
numb the pain of writting the monthly rent check.
You might find that read cacheing is whats
making your benchmarks 'bogus'.
Where do I find the 'bonnie' benchmark s/w?
Here are 2 benchmarks I've had to do recently.
/mnt/ianb/testfile
/tmp files) AND MAKE -j 5
/tmp files) AND MAKE -j 5
/tmp files) AND MAKE -j 5
/tmp files) AND MAKE -j 5
/tmp files)
/tmp files) AND MAKE -j 5
They aren't a complete test of NFS performance
by any means but illustrate that a Network
Appliance (F720) can match local disk performance
and trounce a SUN at NFS server performance.
I would add that though I use linux as an NFS
server at home for my 4 machine network with
few problems, my empirical experience is that
it is not ready for high-load mision critical
NFS server applications.
My opinion is that a Network Appliance's
clever write caching technology reduces the
NFSv2 write penalty dramtically and increases
linux client useability. We run 100+ fast
linux clients and 20+Suns and I know that this
setup is best server ($$$ and performance)
by a Netapp rather than ANY UNIX solution.
This first one shows raw sustained NFS
performance by using dd to read or write a
100MByte file over a switched full duplex
100MBit ethernet between a P-II 333 (3COM 905)
and Redhat 5.2 and a NetApp720.
In summary I can achieve approximately:
33Mbits/sec NFS write performance to the network appliance and
62MBits/sec NFS read performance from the network appliance.
XXX.8x8.com 28: time dd if=/dev/zero of=/mnt/ianb/testfile bs=16k
count=6250
6250+0 records in
6250+0 records out
0.050u 3.740s 0:25.24 15.0% 0+0k 0+0io 96pf+0w
XXX.8x8.com 29: time dd if=/dev/zero of=/mnt/ianb/testfile bs=16k
count=6250
6250+0 records in
6250+0 records out
0.040u 3.840s 0:23.13 16.7% 0+0k 0+0io 95pf+0w
XXX.8x8.com 30: time dd if=/mnt/ianb/testfile of=/dev/null bs=16k
6250+0 records in
6250+0 records out
0.040u 2.690s 0:14.60 18.6% 0+0k 0+0io 99pf+0w
XXX.8x8.com 31: time dd if=/mnt/ianb/testfile of=/dev/null bs=16k
6250+0 records in
6250+0 records out
0.030u 3.150s 0:12.58 25.2% 0+0k 0+0io 114pf+0w
XXX.8x8.com 32: ls -al
-rw-r--r-- 1 ianb users 102400000 Mar 11 10:29
/mnt/ianb/testfile
This 2nd benchmark is a GCC compilation of
8000 lines of C in many files. It illustrates
both the dramtic differences between local
disk/netappNFS/solarisNFS and the benefits
of using gcc and make options to improve
efficiency by running parallel compiles
(which uses idle CPU that is lost whilst the
OS waits for the remote RPC's to complete in an
unparallelized compile) and by using
interprocess comuncation insted of files in
/tmp to communicate between different
compile stages. Conclusion using 100Mbit
network, compile performance approaches local
disk performance.
NADS BUILD (GCC) ON SUN NFS DISK (10Mb/s net)
6.480u 1.460s 0:38.36 20.6% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (100Mb/s net)
6.480u 1.110s 0:29.69 25.5% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (10Mb/s net)
WITH GCC -PIPE (NO
6.890u 1.770s 0:33.17 26.1% 0+0k 0+0io 12597pf+0w
NADS BUILD (GCC) ON SUN NFS DISK (100Mb/s net)
WITH GCC -PIPE (NO
6.660u 1.280s 0:25.22 31.4% 0+0k 0+0io 11736pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (10Mb/s net)
6.650u 1.230s 0:17.67 44.5% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (100Mb/s net)
6.490u 1.250s 0:09.35 82.7% 0+0k 0+0io 12596pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (10Mb/s net)
WITH GCC -PIPE (NO
6.940u 1.430s 0:13.93 60.0% 0+0k 0+0io 11741pf+0w
NADS BUILD (GCC) ON NETAPP NFS DISK (100Mb/s net)
WITH GCC -PIPE (NO
6.830u 1.140s 0:08.77 90.8% 0+0k 0+0io 11736pf+0w
NADS BUILD (GCC) ON LOCAL DISK
5.730u 1.020s 0:11.31 59.6% 0+0k 0+0io 11069pf+0w
NADS BUILD (GCC) ON LOCAL DISK
WITH GCC -PIPE (NO
5.700u 1.040s 0:09.71 69.4% 0+0k 0+0io 10271pf+0w
NADS BUILD (GCC) ON LOCAL DISK
WITH GCC -PIPE (NO
6.000u 1.100s 0:08.19 86.6% 0+0k 0+0io 10280pf+0w