The GPs figures are off. He is using a horrible compiler setup, not only is he using the softfloat calling convention, he is using -mthumb which AIUI will prevent the code from making direct use of the hardware FPU (and I suspect he uwas using debians version of libc preventing indirect use of the hardware fpc through libc routines)at all on armv6. According to hexxeh the povray benchmark under raspbian gives the following results under raspbian on a PI.
Your price figures are off too. An i5 based compute node can be built for more like $500
Similarlly the real price of a Pi node is quite a bit more than $25. Firstly the Pi you can actually buy and would want for this task (clustering needs networking support) has a base price of $35 not $25. Secondly that price excludes things like the power power supply the SD card, the network cable and the mouning hardware. The real cost of a Pi node is probablly more like $50.
So the Pi is about 10 times lower per node than the i5
My overall conclusion is if compute power per dolar is your goal then a smamler number of i5s is a much better bet than a larger numer of Pis.
Making a powered door is pretty easy once you have a usable power source.
Making an automatic door that is both safe and convenient is somewhat harder. Detecting a person is there is easy enough with current tech, determining whether they actually want the door opened is harder. Doors that open whenever someone walks past are annoying in most situations and if people have to press a button to operate the door then there isn't really much advantage over a manual door in most situations*.
* exceptions include massive doors which are a pain to operate by hand and train doors where it is useful for the gaurd to be able to close all the doors without having to walk all the way down the train.
Is that average FPS or minimum FPS? for some reason benchmarkers tend to focus on the former while the latter is what is really important. A game that plays at 20fps solid would probablly be tolerable (it's not much lower than movie framerates after all), one that plays at 30fps most of the time but bogs down in intensive scenes would note.
Note that "best before" is not the same as "use by". AIUI canned food becomes less nice and less nutritious over time but as long as their are no signs of can damage or bloating (which would indicate that bacteria got in somehow) it should be safe indefinately.
What gets me about HE is they don't seem to post their prices anywhere on their website (with the exception of a link advertising ip transit for $1/mbps but giving no details on what requirements you have to meet to get that price...). Their web hosting signup page even asks for credit card details without telling you how much you will be paying!
Personally I wouldn't put my name registrations and my hosting (ideally including DNS hosting) in the same place. There are a couple of reasons for this.
Firstly afaict when the shit hits the fan at a domain name register it is common for the entries in the registery to stay in place but the admin interface to be down. When the shit hits the fan at a hosting provider it is very likely that everything they host goes down. So if your registeration and hosting are at the same provider and the shit hits the fan there you are screwed.If your registration and hosting are at different providers and the shit hits the fan at your regsitration provider you will probablly be ok in the short term. If your registration and hosting are at different providers and the shit hits the fan at your hosting provider then you can move hosting provider.
Secondly it seems prudent to minimise the chance of disputes with a company who can hold your domains hostage by not using them for anything but domain registration.
Really there are two reasons to increase maximum frame size. One is to improve efficiency on the wire, the other is to reduce the number of forwarding descisions to be made.
With improving efficiency on the wire you quickly get into diminishing returns. With 9000 byte frames your header overhead (assuming a TCP/IPv6 session) is probablly of the order of 1%. Reducing that overheard further just isn't going to buy you much more thoughput.
Reducing the number of forwarding decisions would be a legitimate reason to go to larger frames. However given that the main market for high speed ethernet gear is ISPs the vendors have to design their equipment to run at full speed with the packet sizes typically used on the internet.
Do you have a source for that claim? because it seems to me you are remembering articles from the early 2000s that are no longer relavent
Afaict both firewire and modern (full duplex switched) ethernet are low overhead. So it's reasonable to compare them on the basis of their headline data rates
In the early 2000s firewire 400 was starting to appear on desktops and laptops (macs first IIRC but other vendors soon followed because of the digital video craze which at the time was firewire based) while gigabit ethernet wasn't. At this time if you wanted faster networking than 10/100 ethernet then firewire may well have been a good choice. However in the mid 2000s gigabit ethernet started to become readily available. Firewire 800 showed up soon afterwards roughly equalising things but did not see wide adoption outside of macs.
Fast forward to today, gigabit ethernet is standard on pretty much every computer sold. 10 gigabit ethernet is common in core networks of moderate sized providers though it's still too expensive for desktops or regular servers. 100 gigabit is in production with the big carriers but is still a very new thing. Meanwhile firewire seems to have stagnated (1600 and 3200 speeds exist in theory but do not seem to be available in practice) and apple (historicially it's main supporter) seems to be moving away from firewire towards thunderbolt (though they do offer an adaptor for those who want to keep their firewire gear).
The apple thunderbolt cinema display is basically the apple equivilent of a dock. It connects to the mac with thunderbolt and magsafe. It then provides a thunderbolt port for chaining further displays (or hooking up other expensive thunderbolt perhipherals), 4x USB and 1xFW800 for your perhipherals and gigabit ethernet for connecting to your network.
I haven't used one myself though so I don't know how well it all works in practice.
Ah the 16c series USB PICs I remember seeing them in the prouct selection table but then losing interest when I saw them listed as "OTP" (I later discoverered that the OTP designation was not strictly true, they are EPROM based parts, so if you buy them in a windowed package you can UV erase them).
you can still plug the USB PIC micro into a USB 2 port, and it certainly can't support the full 11mbit/s.
Note that interface speed and acheivable throughput are not the same thing. The PIC18f4550 and similar can do full speed and all the examples i've seen run them in full speed mode (you can run them in low speed mode but IIRC you have to lower the core clock to get the right USB clock for low speed).
Still any general purpose USB port has to support low speed so that standard keyboards and mice can be used.
Google has a LOT of servers running much the same workloads. As such it makes sense for them to put in the software engineering effort to achive higher level redundancy. They engineer things so they don't have to care if a server dies.
Most companies have a relatively small number of servers each with a particular task. If one of those servers fails it's a much bigger deal that can mean significant downtime and/or data loss. IIRC restoring a big database from backup and then replaying logs onto it is not a fast process.
They made a choice that was within the C standards, it just happened to be a different one from unix like platforms. When some programmers are assuming long is the same size as pointer and some are assuming that long is exactly 32-bit then the platform vendor is going to have to break some code in the move to 64-bit. The only question is which code.
I also expect that there is a lot more code using long for 32-bit in the windows world than in the unix-like world because 16-bit systems went away much earlier over there.
I had bought HL2 and ended up with another copy of it through a bundle purchase. Lo and behold, I have it listed in my giftable copies.
That is a special case that valve introduced to reduce the uproar of the fans at the cancellation of the black box. It doesn't apply to the vast majority of bundles.
But yes you can get giftable copies of games in variout ways by buying them as gifts, by buying the "two packs" offered for some games (which get you one copy for yourself and one copy to gift) and a few other special cases. Those giftable copies are inventory items that can be given away or traded and the recipiant can do the same.
However to actually play the game the giftable copy must be converted to an entry in the holder's library. This is an irreversable process. So you can't buy (or be given) a game, play it and then resell it/give it away.
steam definately has it's annoyances but having a seperate account and game management platform for each game publisher is going to get far more annoying than having just one of them.
Once a processor is in x64 mode, it cannot run real mode/16-bit code at all. Even virtualized. It's just physically incapable of it.
You are getting confused.
Virtual 8086 mode (used by dos apps) is not supported within long mode but 16-bit protected mode (used by win16 apps) is. Wine running under 64-bit linux can run win16 apps just fine.
IIRC the reason 64-bit windows doesn't support 16-bit apps is because MS were having some problems running wow* on top of wow64 and didn't want to put the development effort into making it work.
* that's windows on windows, not world of warcraft.
Your entire post is either trollish or flamebait. You are terribly misinformed about how PAE works on Windows or Linux.
He made a technical error, windows supports PAE but the vast majority of windows installs out there have cripped PAE support and MS makes you pay through the nose to raise the limits (you have to buy server enterprise or above). Yeah you can hack the kernel to bypass the restrictions but I wouldn't call that a supported configuration.
So for most desktop windows users the only practical way to get support for more memory is to run a 64-bit version.
On any non-PAE enabled 32bit OS the limit is 4GB.
True but only really a problem for windows since linux comes with uncrippled PAE support for free.
Furthermore, you require PAE-capable hardware.
True but afaict all cpus/chipsets that support 64-bit modes also support PAE in 32-bit modes.
Also, PAE is a terrible, performance-degrading hack.
Please provide a reputable source for this claim. The benchmarks I can find seem to show the performance impact as being negligable compared to a plain 32-bit kernel (though interestingly in some tests the 64-bit kernel was far better than either the regular 32-bit kernel or the 64-bit one).
Be aware that if you are porting to more obscure platforms that int may only be 16 bit.
ideally you should use intfast16_t or intfast32_t instead but most people probablly can't be bothered with that.
use long int if you want an int the same size as a pointer.
That will produce code that works on most platforms but that will break horriblly on win64. C makes no gaurantees on the relationship between long and pointer. The type you are looking for is intptr_t.
The biggest problem for 64-bit in the windows world was drivers. Both actual drivers for hardware and apps that used drivers to do "naughty" things. Windows XP proffesional x64 edition was a fine OS but it took a while for MS to bring the hardware and software vendors into line to the point where someone would want to use 64-bit windows as a desktop.
Also for some reason MS didn't support win16 apps on win64, I heard this was because they couldn't be bothered debugging support for it but I dunno if that is true or not.
Finally MS did some braindead stuff like putting 64-bit libraries in system32 and then giving 32-bit apps special views of the filesystem to make up for their braindead location of libraries and putting brackets in the default install path for apps that used 32-bit installers (regardless of whether the app itself is 32 bit or 64 bit).
I am not an intrinsic safety expert but my thoughts:
Modern ethernet (from 10base-T forward) is AC coupled and the signal levels are pretty small, so they may well be low enough that they can be exposed externally provided appropriate protection is in place (and NO POE of course). I doubt anyone cares about 10base-2 and 10base-5 at this point.
As for circuits that must not be exposed to the explosive atmosphere I would guess they usually hardwire it through special glands. If it has to go through connectors they would use special (and expensive) sealed and interlocked ones.
I'd think the biggest problem for equipment in potentially explosive atmospheres would be cooling since enclosures would have to have a gas-tight seal.
Slashdot Mirror
As someone who tried to order Pis through a university early on we didn't get any special treatment.
But anyway the suppliers have been taking multi-unit orders for a while now and the farnell group have actually been filling them.
The GPs figures are off. He is using a horrible compiler setup, not only is he using the softfloat calling convention, he is using -mthumb which AIUI will prevent the code from making direct use of the hardware FPU (and I suspect he uwas using debians version of libc preventing indirect use of the hardware fpc through libc routines)at all on armv6. According to hexxeh the povray benchmark under raspbian gives the following results under raspbian on a PI.
Total Scene Processing Times
Parse Time: 0 hours 0 minutes 16 seconds (16 seconds)
Photon Time: 0 hours 5 minutes 57 seconds (357 seconds)
Render Time: 6 hours 13 minutes 57 seconds (22437 seconds)
Total Time: 6 hours 20 minutes 10 seconds (22810 seconds)
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175
Your price figures are off too. An i5 based compute node can be built for more like $500
Similarlly the real price of a Pi node is quite a bit more than $25. Firstly the Pi you can actually buy and would want for this task (clustering needs networking support) has a base price of $35 not $25. Secondly that price excludes things like the power power supply the SD card, the network cable and the mouning hardware. The real cost of a Pi node is probablly more like $50.
So the Pi is about 10 times lower per node than the i5
My overall conclusion is if compute power per dolar is your goal then a smamler number of i5s is a much better bet than a larger numer of Pis.
You may say, "Hey, this test is running using soft-float! If you used hard float, it'd be faster!"
Massively faster
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175
IMO powered door != automatic door.
Making a powered door is pretty easy once you have a usable power source.
Making an automatic door that is both safe and convenient is somewhat harder. Detecting a person is there is easy enough with current tech, determining whether they actually want the door opened is harder. Doors that open whenever someone walks past are annoying in most situations and if people have to press a button to operate the door then there isn't really much advantage over a manual door in most situations*.
* exceptions include massive doors which are a pain to operate by hand and train doors where it is useful for the gaurd to be able to close all the doors without having to walk all the way down the train.
Dell tried locking their raid controllers to their own drives but backed down under customer pressure.
http://www.standalone-sysadmin.com/blog/2010/04/dell-reverses-position-on-3rd-party-drives/
the difference between 40fps and 20fps
Is that average FPS or minimum FPS? for some reason benchmarkers tend to focus on the former while the latter is what is really important. A game that plays at 20fps solid would probablly be tolerable (it's not much lower than movie framerates after all), one that plays at 30fps most of the time but bogs down in intensive scenes would note.
Note that "best before" is not the same as "use by". AIUI canned food becomes less nice and less nutritious over time but as long as their are no signs of can damage or bloating (which would indicate that bacteria got in somehow) it should be safe indefinately.
What gets me about HE is they don't seem to post their prices anywhere on their website (with the exception of a link advertising ip transit for $1/mbps but giving no details on what requirements you have to meet to get that price...). Their web hosting signup page even asks for credit card details without telling you how much you will be paying!
Personally I wouldn't put my name registrations and my hosting (ideally including DNS hosting) in the same place. There are a couple of reasons for this.
Firstly afaict when the shit hits the fan at a domain name register it is common for the entries in the registery to stay in place but the admin interface to be down. When the shit hits the fan at a hosting provider it is very likely that everything they host goes down. So if your registeration and hosting are at the same provider and the shit hits the fan there you are screwed.If your registration and hosting are at different providers and the shit hits the fan at your regsitration provider you will probablly be ok in the short term. If your registration and hosting are at different providers and the shit hits the fan at your hosting provider then you can move hosting provider.
Secondly it seems prudent to minimise the chance of disputes with a company who can hold your domains hostage by not using them for anything but domain registration.
Really there are two reasons to increase maximum frame size. One is to improve efficiency on the wire, the other is to reduce the number of forwarding descisions to be made.
With improving efficiency on the wire you quickly get into diminishing returns. With 9000 byte frames your header overhead (assuming a TCP/IPv6 session) is probablly of the order of 1%. Reducing that overheard further just isn't going to buy you much more thoughput.
Reducing the number of forwarding decisions would be a legitimate reason to go to larger frames. However given that the main market for high speed ethernet gear is ISPs the vendors have to design their equipment to run at full speed with the packet sizes typically used on the internet.
It blows away Ethernet.
Do you have a source for that claim? because it seems to me you are remembering articles from the early 2000s that are no longer relavent
Afaict both firewire and modern (full duplex switched) ethernet are low overhead. So it's reasonable to compare them on the basis of their headline data rates
In the early 2000s firewire 400 was starting to appear on desktops and laptops (macs first IIRC but other vendors soon followed because of the digital video craze which at the time was firewire based) while gigabit ethernet wasn't. At this time if you wanted faster networking than 10/100 ethernet then firewire may well have been a good choice. However in the mid 2000s gigabit ethernet started to become readily available. Firewire 800 showed up soon afterwards roughly equalising things but did not see wide adoption outside of macs.
Fast forward to today, gigabit ethernet is standard on pretty much every computer sold. 10 gigabit ethernet is common in core networks of moderate sized providers though it's still too expensive for desktops or regular servers. 100 gigabit is in production with the big carriers but is still a very new thing. Meanwhile firewire seems to have stagnated (1600 and 3200 speeds exist in theory but do not seem to be available in practice) and apple (historicially it's main supporter) seems to be moving away from firewire towards thunderbolt (though they do offer an adaptor for those who want to keep their firewire gear).
The apple thunderbolt cinema display is basically the apple equivilent of a dock. It connects to the mac with thunderbolt and magsafe. It then provides a thunderbolt port for chaining further displays (or hooking up other expensive thunderbolt perhipherals), 4x USB and 1xFW800 for your perhipherals and gigabit ethernet for connecting to your network.
I haven't used one myself though so I don't know how well it all works in practice.
Ah the 16c series USB PICs I remember seeing them in the prouct selection table but then losing interest when I saw them listed as "OTP" (I later discoverered that the OTP designation was not strictly true, they are EPROM based parts, so if you buy them in a windowed package you can UV erase them).
you can still plug the USB PIC micro into a USB 2 port, and it certainly can't support the full 11mbit/s.
Note that interface speed and acheivable throughput are not the same thing. The PIC18f4550 and similar can do full speed and all the examples i've seen run them in full speed mode (you can run them in low speed mode but IIRC you have to lower the core clock to get the right USB clock for low speed).
Still any general purpose USB port has to support low speed so that standard keyboards and mice can be used.
And google is not your average company.
Google has a LOT of servers running much the same workloads. As such it makes sense for them to put in the software engineering effort to achive higher level redundancy. They engineer things so they don't have to care if a server dies.
Most companies have a relatively small number of servers each with a particular task. If one of those servers fails it's a much bigger deal that can mean significant downtime and/or data loss. IIRC restoring a big database from backup and then replaying logs onto it is not a fast process.
Oh, they even managed to fuck that up!
They made a choice that was within the C standards, it just happened to be a different one from unix like platforms.
When some programmers are assuming long is the same size as pointer and some are assuming that long is exactly 32-bit then the platform vendor is going to have to break some code in the move to 64-bit. The only question is which code.
I also expect that there is a lot more code using long for 32-bit in the windows world than in the unix-like world because 16-bit systems went away much earlier over there.
What is sizeof(long)? 4? 16?
4
I had bought HL2 and ended up with another copy of it through a bundle purchase. Lo and behold, I have it listed in my giftable copies.
That is a special case that valve introduced to reduce the uproar of the fans at the cancellation of the black box. It doesn't apply to the vast majority of bundles.
But yes you can get giftable copies of games in variout ways by buying them as gifts, by buying the "two packs" offered for some games (which get you one copy for yourself and one copy to gift) and a few other special cases. Those giftable copies are inventory items that can be given away or traded and the recipiant can do the same.
However to actually play the game the giftable copy must be converted to an entry in the holder's library. This is an irreversable process. So you can't buy (or be given) a game, play it and then resell it/give it away.
steam definately has it's annoyances but having a seperate account and game management platform for each game publisher is going to get far more annoying than having just one of them.
Once a processor is in x64 mode, it cannot run real mode/16-bit code at all. Even virtualized. It's just physically incapable of it.
You are getting confused.
Virtual 8086 mode (used by dos apps) is not supported within long mode but 16-bit protected mode (used by win16 apps) is. Wine running under 64-bit linux can run win16 apps just fine.
IIRC the reason 64-bit windows doesn't support 16-bit apps is because MS were having some problems running wow* on top of wow64 and didn't want to put the development effort into making it work.
* that's windows on windows, not world of warcraft.
Your entire post is either trollish or flamebait.
You are terribly misinformed about how PAE works on Windows or Linux.
He made a technical error, windows supports PAE but the vast majority of windows installs out there have cripped PAE support and MS makes you pay through the nose to raise the limits (you have to buy server enterprise or above). Yeah you can hack the kernel to bypass the restrictions but I wouldn't call that a supported configuration.
So for most desktop windows users the only practical way to get support for more memory is to run a 64-bit version.
On any non-PAE enabled 32bit OS the limit is 4GB.
True but only really a problem for windows since linux comes with uncrippled PAE support for free.
Furthermore, you require PAE-capable hardware.
True but afaict all cpus/chipsets that support 64-bit modes also support PAE in 32-bit modes.
Also, PAE is a terrible, performance-degrading hack.
Please provide a reputable source for this claim. The benchmarks I can find seem to show the performance impact as being negligable compared to a plain 32-bit kernel (though interestingly in some tests the 64-bit kernel was far better than either the regular 32-bit kernel or the 64-bit one).
Use int for "normal" ints.
Be aware that if you are porting to more obscure platforms that int may only be 16 bit.
ideally you should use intfast16_t or intfast32_t instead but most people probablly can't be bothered with that.
use long int if you want an int the same size as a pointer.
That will produce code that works on most platforms but that will break horriblly on win64. C makes no gaurantees on the relationship between long and pointer. The type you are looking for is intptr_t.
The biggest problem for 64-bit in the windows world was drivers. Both actual drivers for hardware and apps that used drivers to do "naughty" things. Windows XP proffesional x64 edition was a fine OS but it took a while for MS to bring the hardware and software vendors into line to the point where someone would want to use 64-bit windows as a desktop.
Also for some reason MS didn't support win16 apps on win64, I heard this was because they couldn't be bothered debugging support for it but I dunno if that is true or not.
Finally MS did some braindead stuff like putting 64-bit libraries in system32 and then giving 32-bit apps special views of the filesystem to make up for their braindead location of libraries and putting brackets in the default install path for apps that used 32-bit installers (regardless of whether the app itself is 32 bit or 64 bit).
which 64-bit versions of Windows won't run,
What really amuses me is that 16 bit windows apps won't run on 64-bit windows but they do run on 64-bit linux.
I am not an intrinsic safety expert but my thoughts:
Modern ethernet (from 10base-T forward) is AC coupled and the signal levels are pretty small, so they may well be low enough that they can be exposed externally provided appropriate protection is in place (and NO POE of course). I doubt anyone cares about 10base-2 and 10base-5 at this point.
As for circuits that must not be exposed to the explosive atmosphere I would guess they usually hardwire it through special glands. If it has to go through connectors they would use special (and expensive) sealed and interlocked ones.
I'd think the biggest problem for equipment in potentially explosive atmospheres would be cooling since enclosures would have to have a gas-tight seal.
sha256 is overkill but CRC32 is too small and in a system with 4.2 million files is almost certain to produce false positives.
The expected number of false positives with crc32 is arround 4200000^2 / 2 / 2^32 ~= 2054