It is always best to recharge NiMh batteries overnight. Just buy enough batteries so you always have a set sitting in the recharger. NiMh chargers generally push current into the battery and limit based on temperature for a fixed period of time (initiated by unplugging then plugging the charger in), which gets the battery 95% of the way there. The charger then goes into trickle charge/upkeep mode which tops off the battery and can be used to keep its charge up. You can safely leave a set of NiMh batteries in its charger for weeks (and I do).
NiMh batteries do not have a memory and will last years. They run at slightly lower voltages (e.g. 1.2 instead of 1.5 in AA) which often throws battery guages off but otherwise work just fine. They are not high current devices (which is why you still often see NiCd in things like electric razors) but they work well for most applications.
When purchasing NiMh batteries get at *least* 1500 mAH capacities (for AA). The higher the capacity, the better, but 1500 and 1600 is the benchmark for AA.
I have several dozen NiMh AA's. I use them in everything from cameras to FRS radios to remote controls and clocks. In clocks they last 6+ months between recharges. In remotes they last about 6 months between recharges. In FRS radios they last the day. In cameras they are ok but Li-ion battery packs are far superior and most digital camera makers, like Canon for example, have shifted to Li-ion.
I've been investigating cameras to replace my CanonG2, and so far the Canon 10D in the $1300 range beats everything else hands down. Spending $3000 on the Nikon *just* to get WIFI is serious waste of money, it would be far better to get something like the Canon 10D and then spend all the money you just saved on some good lenses and hi capacity storage.
The single most important improvement in digital cameras in the last year is that they have finally made good progress fixing the digital noise issues at high ASA settings, followed closely by shutter lag and auto-focus improvements. Canon has done a slam bang job in all regards and their in-camera processing software is also the best of the lot insofar as I can tell.
Don't let highly touted statistics like FPS or mega-pixels fool you, it's all for naught if your camera can't take a good picture and runs out of power after an hour or two of use.
You know, I hear this junk all the time and I can only conclude that the people who spout it off have no real understanding of what the BSD or GPL licenses actually are, let alone their respective effects on the environment around them. The hype has far outstripped the reality and the result are hoards of young programmers slapping the GPL on trivia and minutia that has no other effect then that of relegating their bits to the dustbin of history. And the really sad thing is that it can take years sometimes to realize you've screwed yourself when, say, ten years down the line you want to use work you did on a collaborative project for something that doesn't quite fit the license and find you can't because you have no idea who else to contact to unwind the GPL'd mess. Oops! I find
the GPL useful only if I intend to potentially relicense to commercial entities under separate cover and that is pretty much it. The BSD does a better job, statistically, in polluting commercial source bases with open standards and always will. Even microsoft's attempts to proprietize BSD licensed code has resulted in a far greater adoption of open standards, such as with kerberos, then if they had written their own from scratch which would have been 100% proprietary instead of only 5% proprietary. TCP and DNS also come to mind. Those were big wins for our side folks, mostly looked over because you idiots focused in on what microsoft tried to do rather then the actual big picture effect of what they wound up doing.
The problem with the GPL is that it doesn't trust its fate to human nature but instead tries to force an effect that tends to be against human nature. GPL is a license based on fear and uncertainty, at least from an idealogical standpoing. The BSD license recognizes human nature and works with it to far greater effect for the society as a whole. I prefer trust to fear. I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it. That is the reality of the GPL. I use it occassionally, but for commercial reasons only. Everything else I do under the BSD.
There are many Amiga-like concepts incorporated into the model, and plenty of new stuff as well. The Amiga had a highly optimal messaging system oweing to the fact that it ran on such a slow cpu making every cycle golden. Two features have been taken from the Amgia I/O model. First, the idea that the target can choose to perform an operation synchronously or asynchronously entirely independant of the type of operation the client has requested. In the Amiga model the client passes a hint which the target may choose to act on or choose to ignore and so do we.
Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.
To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.
Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.
That is the crux of the issue. The problem is that while a great deal of work has gone into FreeBSD-5.x, it is all based on a fine-grained mutex locking MP model that is simply not compatible with the methodologies being implemented for DragonFly. 4.x isn't actually 'old', a good deal of non-MP related work has been merged from 5.x into 4.x. We miss out on a few big things, like UFS2, snapshots, and the security infrastructure in 5.x, but 6 months down the road when we have our new infrastructure in place reimplementing those items will be a trivial exercise. Also, 4.x is a far more stable base to work from then 5.x.
Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.
You are welcome, and ditto to the other followup poster! Now for the scary part: Despite the demise of the Amiga there are still people who use DICE, and DASM (65xx/687xx assembler). Apparently DASM has become a favorite in the classic Atari world. There are also still many old hardware installations based on the 68K and DICE is one of the few (complete) compiler toolsets for the 68K that can be run on a modern platform. Yow!
Not quite correct. You do not need precise timing to implement TCP Vegas or similar schemes. RTTs are inherently noisy no matter what you do and being able to precisely time them does not actually make things any easier. You need to calculate the RTTs using high precision in storage, but the actual calculation can obtain that precision statistically over many lower-resolution samples. The standard 1/100 sec timing granularity (e.g. the standard clock interrupt used by many UNIXes these days) is plenty sufficient. See my description of TCP Vegas further on down.
Well, the results would certainly be different. Whether the results would be better or worse is completely up in the air since it only takes minor tweaks to TCP to create wildly different results in a contrived (verses real-life) test. A better result in a contrived test does not necessarily mean a better implementation.
For example, on a perfect link with no packet loss and only one or two volume TCP connections going, New Reno will beat TCP Vegas by about 5% (as well as the algorithm I implemented in FreeBSD). This doesn't make NewReno better, because all NewReno is doing is just slamming the packets through without regard for anything else that might be going over the same link, but if all that is being tested is throughput (and not the latency of other connections), then it would appear that NewReno is better.
Another example: The TCP spec suggests a minimum retransmission timeout (RTO) of 1 second in order to avoid occassional retransmission of packets and issues related to broken delayed-ack implementations. But blindly following this suggestion completely destroys TCP's *INTERACTIVE* performance over a low-latency high-speed connections like, for example, 802.11b. A TCP implementation that allows RTOs of less then 1 second (ala FreeBSD-5 by default and a sysctl in FreeBSD-4) in exchange for occassional unnecessary retransmissions will have a far better performance over a lossy link being used interactively but slightly worst performance over a perfect link being used for volume data transfer. Which is better is in the eye of the beholder... it would depend entirely on the test parameters applied.
The difference between TCP Vegas and New Reno's congestion control is that TCP Vegas attempts to calculate a stabilized bandwidth-delay product to measure the available bandwidth of the channel and then matches the bandwidth of the TCP connection to the bandwidth of the channel. New Reno depends on intermediate routers dropping packets to detect 'congestion'. TCP Vegas does not depend on feedback (in the form of missed packets) at all, really, and certainly does not depend on direct feedback from intermediate routers (beyond measuring perceived amount buffering being built up in those routers through the bandwidth-delay product calculation).
The core stabilizing parameter of the TCP Vegas implementation is the measurement of the minimum observed RTT over the connection. No other RTT measurement is stable. For example, both the instantanious and the long-term-averaged RTT measurement creates a positive feedback situation in the core calculation (i.e. NOT stable if used alone). The minimum RTT measurement cannot be used alone without making the algorithm non-responsive to changes in available channel bandwidth, but it can be used to anchor and stabilize the algorithm and that is what TCP Vegas does.
The problem with New Reno is that most routers do not drop packets until their queues are already mostly full... far too late (i.e. the RTTs have already gone out of control by the time intermediate nodes finally decide to start dropping packets), and even running something like RED is only a hack to try to drop packets earlier, before it is too late. Anything that depends on ALL intermediate nodes physically dropping packets according to a TCP-optimized algorithm to generate implied feedback for TCP is a stupid and unnecessary approach in my view.
TCP Vegas is very similar to the algorithm I implemented in FreeBSD (the net.inet.tcp.inflight_enable sysctl). Both attempt to calculate the available channel bandwidth and adjust a TCP connection to fit the available bandwidth. Both have the same problem in that calculating the channel bandwidth depends on calculating the bandwidth-delay product which depends on a stable RTT, and the RTT is *NOT* stable when a channel is near or at its rated bandwidth. This is why both TCP Vegas and the algorithm I implemented in FreeBSD use the minimum observed RTT as a basis for the bandwidth-delay product calculation rather then the currently observed RTT or the long-term-averaged RTT (neither of which is stable if used alone). Both Vegas and the algorithm implemented in FreeBSD can still handle changes in available channel bandwidth within a reasonable range, but it isn't perfect because both must still be anchored using the only stable measurement available (the minimum observed RTT), and it is not possible to make it perfect due to the extreme instability of nearly all other measurements both the TCP server and TCP client could make during a connection.
NewReno's "wait for intermediate nodes to drop packets" method of congestion control is *COMPLETELY* broken. The only reason it works at all is because most TCP connections use fairly small advertised windows. When you use large advertised windows everything blows up. TCP Vegas and the FreeBSD algorithm can handle large advertised windows without blowing up.
It should be interesting to see what the FAST group comes up with, but I think they don't quite understand the extreme instabilities of the calculations being made. TCP Vegas does a fairly good job as does the algorithm in FreeBSD (both using the minimum observed RTT as an anchor in the calculations). Neither is perfect, but finding something better that manages to remain stable over a wide range of situations is not going to be a walk in the park.
Getting maximum throughput over 100BaseT is easy, and 11.5 MBytes/sec sounds about right. 100BaseT switches are cheap these days (far cheaper then the WIFI stuff being talked about in this thread) and just about every 100BaseT NIC sold can autonegotiate full duplex.
Also, keep in mind that the so-called 200MBits of maximum bandwidth really only means 'full duplex', i.e. 100MBits in both directions simultaniously, not 200MBits in one direction. And even cheap 100BaseT switches are single-chip solutions with 5Gbit or better backplanes (being all on a single chip) and can do that no sweat.
I would go as far as to say, at least for in-home use, it's far better to invest in the slower and cheaper 802.11b WIFI gear and spend the money you save on wiring your house with 100BaseT, because regardless of the speed of the WIFI gear a hardline is always going to be an order of magnitude more responsive and far more reliable. I have netbooted machines on both hardlines and WIFI and I can say that rather definitively.
Re:US Robotics: 100Mbit WLAN, should I buy it ?
on
802.11g Slows Down
·
· Score: 1
US Robotics? Remember the whole 56K modem mess, where manufacturers wound up with a dozen variations of two different incompatible standards that could barely talk to each other?
That is where 802.11g is. Only fools and the rich are buying it right now. I'll consider it a year or two after the standard has been laid in stone, because that is how long it is going to take for the various vendors to get onto the right track and for competition to push pricing down to reasonable levels. Buying into 802.11g now is a waste of time and money.
Even now 802.11b is barely up to the task, and vendors have had plenty of time to clean up their buggy firmware. I have 801.11b bridges that crash when running at the edge of their range, that can't auto-speed reliable, and base stations that can't transparently pass DHCP through (amoung other horrors). I'd rather the vendors fix all the problems with their existing offerings before they go running off into a new nirvana of buggy high speed devices that only work reliably at distances of less then 50 feet.
I gave up on tapes long ago, as have most of my friends including one who owns and operates a small ISP. Simply put: Tapes are not as reliable or as easy to deal with as hard drives. For every hard drive that has ever failed on me, 10 tapes have failed on me. The tape media and tape drives simply change too often, destroying the one historical benefit of tape (long term archival), and tapes are a pain to deal with even with a robotic tape library. So these days all my backups are handled from a secure machine which runs no incoming services at all, not even sshd. The machine uses outgoing ssh to pull in daily incrementals and weekly fulls from all the other machines on the LAN as well as a few over the internet. I give my family and friends ftp space on one of my boxes and they backup their data over their DSL connections to my box and I back it up again to my backup box along with everything else.
And what is the media used in the backup box? A cheap removable IDE drive. Stickem or not, if worst came to worst the media is still far more recoverable (and I've never had to resort to a recovery service, so the cost is obviously low even if it does happen occassionally). I plan on upgrading the backup box to use a cheap IDE RAID controller in a few weeks, mainly so I can expand the storage and stage out the drives. Nothing expensive or fancy.
Problem solved.
You guys are confused... UNIX always uses GMT (1)
on
Daylight Savings and UNIX?
·
· Score: 2, Insightful
Internally UNIX always uses GMT (1), period. time() always returns epoch time. It is not effected by daylight savings time or zone changes. NTP keeps epoch time in synch. It is not effected by daylight savings time or zone changes either.
Your time zone preference can be set on a shell-by-shell basis or process-by-process basis using the TZ environment variable. The system has a default preference that is typically/etc/localtime. In short, the system doesn't care what your preference is. The preference only effects display representations, it does not effect the underlying timekeeping.
Programs can choose to use whatever timezone they wish independant of any preference. It just so happens that cron defaults to using the system local time preference but nothing prevents you from changing that if you don't like it. In fact, many cron's allow you to set the time zone you want to specify your jobs in on a user-by-user basis. So if cron's skipping around is bothering you, just switch it to GMT (1).
(note 1: well, it's either GMT or UTC, I forget which. There are subtle differences)
35mm film is roughly equivalent to 50 megapixels, especially if you know what you are doing with it. A 4 megapixel digital camera (my Canon G2 for example) has sufficient resolution for an 8.5x11 print without pixelation but isn't even within shouting distance of film in regards to dynamic range. 10 bits per pixel just isn't enough, you need at least 16 bits per pixel to match film. This is fairly easy to demonstrate.
That said, the only time I use film any more is in extreme low light situations and even then I usually don't bother if I can get the equivalent with a long-exposure on my G2.
I have to doubly agree in regards to system limits. FreeBSD's default limits are quite generous, and if you have to exceed them then you need to do some minor tuning. It is true that the limits were too conservative in older releases but that problem has been largly fixed over the last few years and most tunables can now be modified on a running system without having to compile the kernel. This is preferable to the Linux "I'll happily allocate all the system's resources to XXX if XXX happens to need it" methodology. Why? Because the allocate-as-much-as-appears-to-be-needed methodology only works when you only have one or possibly two heavily loaded resources. The moment you have more then that the system dies a horrible death or thrashes itself to pieces. And god help you if such a system is DOSsed!
So while it is true that you tend to need to tune FreeBSD a bit more in an extreme environment, what you get out of it is far better stability and far more consistency under load. And *THAT* is why people use FreeBSD in those environments.
In anycase, I can see how this view happened. Earlier versions of FreeBSD were definitely overly conservative in regards to disk layout and system resources. But that's old news. It isn't the case anymore and hasn't been for quite some time.
It's even easier then that. With FreeBSD you can use read-only NFS exports to distribute both ports, the code base, and even/usr/obj. I usually do all my system builds on a single machine, NFS mount that host's/usr/src and/usr/obj on other boxes, build the world on one box and simply 'make installworld' on the other boxes. For more localized control I would simply export/usr/src and leave/usr/obj local on each host.
Similar tricks can be done with ports through the use of a R+W exported/usr/ports but I personally use a method that only requires a read-only/usr/ports export. It's really simple: On your master machine make/usr/ports/distfiles a softlink to/usr/ports.distfiles, mkdir the local/usr/ports.distfiles (on all the boxes), and in/etc/make.conf (on all the boxes) set WRKDIRPREFIX to a local filesystem with enough space. Then you can simply NFS export/usr/ports to your other boxes. To avoid downloading the distfile multiple times you can leave/usr/ports/distfiles alone and export that (read-only for safety), then simply build the port on the master server (no need to install it) and the distfiles will be there for the clients.
That coupled with a nightly cvsup on the server and every single box you have will have access to the latest and greatest with no effort at all.
Right, but it's slightly more complicated then that. What is really going on is that the nearly resonent wave is interfering with the signal wave, canceling out the stretching effect you get. That is, different frequency components of any EM wave will travel at different velocities with the fastest component going near the speed of light. So the information packet stretches as it goes down the wire. Conventional electronics cannot predict the entire wave from just the fastest component but the universe can as a quantum mechanical effect. You can't pass information without multiple frequency components (even just changing the phase will temporarily create additional frequency components, which stretch). In anycase, since conservation of energy is required by the universe (at least so far), the canceling out of the slower components of the wave causes the energy associated with those components to accumulate in the faster components of the wave. These faster components happen to be moving at near the speed of light so, overall, you wind up with a non-attenuated (or less attenuated) signal at the far end whos entire contents reaches the far end at near the speed of light.
Now the complication: you cannot simply create a resonent wave to cancel out the slower components at point X because you do not know what those slower components are at point X (they haven't arrived yet). But since the signal itself knows (quantum mechanically speaking), you can use reflections of the signal itself, at near resonence, to cancel out portions of itself which have not yet arrived. Confused yet? The result is that the cancelation gives the whole signal 'a push'. This cancelation effect appears to move faster then the speed of light because it is canceling a wave that has not yet arrived. This is the phase velocity they are talking about I think. but it is only using information that has traveled at the speed of light (quantum mechanically speaking the universe only needs the leading edge of the attenuated signal to know the whole signal), so there is no way this technology could be used to actually achieve FTL data transfer.
This is for real, a number of universities have been working on it for years. How useful it winds up being in the end is a matter of opinion, though.
You can access pictures I took during the FreeBSD summit (Click Here). There were some great moments and since I was putting the pics up in near real time the folks coming in on the conference call were effectively there in person.
Just for the hell of it I ran the same benchmarks on one of my test boxes (FreeBSD running -current). The performance basically comes down to how much write latency you are willing to endure... the longer the latency, the better the benchmark results for the first two tests.
So, for example, with the (conservative) system defaults I only got around 250 trans/sec for mixed creations with the first postmark test, because the system doesn't allow more then around 18MB of dirty buffers to build up before it starts forcing the data out, and also does not allow large sequential blocks of dirty data to sit around. When I bump up the allowance to 80MB and turn off full-block write_behind the trans rate went up to 2776/sec. I got similar characteristics for the second test as well.
Unfortunately I have only one 7200 rpm hard drive on this box so I couldn't repeat the third test in any meaningful way (which is a measure mostly of disk bandwidth).
In anycase, the point is clear, and the authors even mention it by suggesting that the ext3 write-back mode should only be used with NVRAM. Still, I don't think they realize that their RedHat box likely isn't even *writing* the data to the disk/NVRAM until it absolutely has to, so arbitrarily delaying writes for what is supposed to be a mail system is not a good evaluation of performance. Postmark does not fsync() any of the operations it tests whereas any real mail system worth its salt does, and even with three drives striped together this would put a big crimp on the reported numbers unless you have a whole lot of NVRAM in the RAID controller.
I do not believe RedHat does the write-behind optimization that FreeBSD does. This optimization exists specifically to maximize sequential performance without blowing up system caches (vs just accumulating dirty buffers). But while this optimization is good in most production situations it also typically screws up non-sequential benchmark numbers by actually doing I/O to the drive when the benchmark results depend on I/O not having been done:-).
Last thought. Note that the FreeBSD 4.6 release has a performance issue with non-truncated file overwrites (not appends, but the 'rewrite without truncation' type of operation). This was fixed post-release in -stable.
I'll lay it out. Obviously Google is not storing the master copy of the full multi-terrabyte database in ram, but they are certainly storing as big a chunk in ram as they can, and the cost model ought to be easy for anyone to understand if you sit down and think about it.
Consider the cost difference between the following EQUAL amounts of hard disk storage:
* A 160GB IDE drive
* A 160GB SCSI drive
* Four 40GB drives in an external RAID system
* The cost of a small medium-performance RAID
system.
* The cost of a larger high-performance RAID
system scaleability to a terrabyte.
* The cost of an *EXTREMELY* high performance RAID
system scaleability to multiple terrabytes.
Now consider the cost of building, say, a 40 terrabyte data store (lets not worry about backups for this experiment). If you build it out of a bunch of huge SCSI drives connected to a bunch of PC's it can be fairly cheap. But if you build out of, say, high performance EMC arrays it could cost millions of dollars more to get the same theoretical performance.
So when you consider the cost of storage, you always have to consider the cost of the PERFORMANCE you want to get out of that storage. All the Google CEO is saying is that, Doh! It's a hellofalot cheaper to improve the performance aspects of the system by buying DRAM in a distributed-PC environment in order to be able to avoid having to purchase extremely-high performance (and extremely expensive) disk subsystems. The cost of purchasing the DRAM to make up for the lower-performing disk subsystem is actually LOWER then the cost of purchasing an equivalent higher-performance disk subsystem.
The same is true in the ISP world. When RAM was expensive we had to rely on big whopping HD systems to scale machines up. But when RAM became cheap it turned out that you could simply throw in a very high density drive with 1/4 the performance that four smaller drives would give you, and the operating system's RAM cache would take care of the problem. Suddenly we no longer needed to purchase big whopping disk arrays.
Find an old Commodore Pet computer on the junk heap somewhere. Turn it on, make sure the monitor still works, and extract the TTL digital input wire from the internal monitor cable while leaving the remaining wires connected. You can then use this (and ground) to probe TTL signals up to around 7MHz:-)
Alternatively you can go to CompUsa and spend $60 on a cheap oscilloscope.
Slashdot Mirror
NiMh batteries do not have a memory and will last years. They run at slightly lower voltages (e.g. 1.2 instead of 1.5 in AA) which often throws battery guages off but otherwise work just fine. They are not high current devices (which is why you still often see NiCd in things like electric razors) but they work well for most applications.
When purchasing NiMh batteries get at *least* 1500 mAH capacities (for AA). The higher the capacity, the better, but 1500 and 1600 is the benchmark for AA.
I have several dozen NiMh AA's. I use them in everything from cameras to FRS radios to remote controls and clocks. In clocks they last 6+ months between recharges. In remotes they last about 6 months between recharges. In FRS radios they last the day. In cameras they are ok but Li-ion battery packs are far superior and most digital camera makers, like Canon for example, have shifted to Li-ion.
-Matt
The single most important improvement in digital cameras in the last year is that they have finally made good progress fixing the digital noise issues at high ASA settings, followed closely by shutter lag and auto-focus improvements. Canon has done a slam bang job in all regards and their in-camera processing software is also the best of the lot insofar as I can tell.
Don't let highly touted statistics like FPS or mega-pixels fool you, it's all for naught if your camera can't take a good picture and runs out of power after an hour or two of use.
-Matt
The problem with the GPL is that it doesn't trust its fate to human nature but instead tries to force an effect that tends to be against human nature. GPL is a license based on fear and uncertainty, at least from an idealogical standpoing. The BSD license recognizes human nature and works with it to far greater effect for the society as a whole. I prefer trust to fear. I'm just not the paranoid type and if one doesn't have commercial motives for using the GPL one really has to have a high level of paranoia to justify it. That is the reality of the GPL. I use it occassionally, but for commercial reasons only. Everything else I do under the BSD.
-Matt
Another feature taken from the Amiga I/O model (for those who ever looked at the actual assembly code) is the ability to short-cut queueing operations. For example, if the target is able to execute a message synchronously regardless of what the client requested, the target can execute the message in the client's context and return a synchronous result code without even bothering to queue the message (I/O request in Amiga terminology). Likewise, if the client wants to run an operation synchronously and the target decides to run it asynchronously the target doesn't have to queue the message back to the client's reply port when it is through, it simply wakes the (blocked) client up.
To make messaging truely efficient the 'optimal' case must have the lowest possible overhead. The Amiga model serves this requirement very nicely, making optimally handled messages take no more overhead then a subroutine call would take. This is extremely important in an MP design because queueing operations often require some sort of lock and being able to avoid a queueing operation in the optimal case is simply *HUGE*.
Consider the optimal syscall path given the above. If a syscall can run without blocking your syscall 'message' winds up costing no more then a traditional syscall would. After all, there is no point asynchronizing a syscall that can run without blocking, you only have one cpu for any given userland thread anyway so you can't make things faster by switching out to handle something else and then back again. Yet in a traditional asynchronizing model like AIO, a great deal of effort and overhead is taken before you even know whether the I/O operation would block or not, making AIO expensive no matter how you cut it. The same goes with a select() based operation. And in a KSE style operation the expense occurs in having to maintain multiple kernel threads for system calls which are in-progress, instead of much smaller message structuers for system calls which are in-progress. The above Amiga-like features make it possible to encapsulate *ALL* system calls in messages, request asynchronous completion, yet still deal with synchronous completion in a manner which does not introduce a performance penalty.
Insofar as performance goes, a higher version number does not mean higher performance. 4.x is a lot faster then 5.x for many types of tasks. DragonFly will be able to implement critical subsystems in MP, like the TCP stack, using an essentially mutexless design, which ultimately means that DragonFly will theoretically be able to perform better then 5.x in an MP environment once both are able to completely remove the MP lock. But that is down the road quite a bit and a lot can happen between then and now.
-Matt
Not quite correct. You do not need precise timing to implement TCP Vegas or similar schemes. RTTs are inherently noisy no matter what you do and being able to precisely time them does not actually make things any easier. You need to calculate the RTTs using high precision in storage, but the actual calculation can obtain that precision statistically over many lower-resolution samples. The standard 1/100 sec timing granularity (e.g. the standard clock interrupt used by many UNIXes these days) is plenty sufficient. See my description of TCP Vegas further on down.
For example, on a perfect link with no packet loss and only one or two volume TCP connections going, New Reno will beat TCP Vegas by about 5% (as well as the algorithm I implemented in FreeBSD). This doesn't make NewReno better, because all NewReno is doing is just slamming the packets through without regard for anything else that might be going over the same link, but if all that is being tested is throughput (and not the latency of other connections), then it would appear that NewReno is better.
Another example: The TCP spec suggests a minimum retransmission timeout (RTO) of 1 second in order to avoid occassional retransmission of packets and issues related to broken delayed-ack implementations. But blindly following this suggestion completely destroys TCP's *INTERACTIVE* performance over a low-latency high-speed connections like, for example, 802.11b. A TCP implementation that allows RTOs of less then 1 second (ala FreeBSD-5 by default and a sysctl in FreeBSD-4) in exchange for occassional unnecessary retransmissions will have a far better performance over a lossy link being used interactively but slightly worst performance over a perfect link being used for volume data transfer. Which is better is in the eye of the beholder... it would depend entirely on the test parameters applied.
The core stabilizing parameter of the TCP Vegas implementation is the measurement of the minimum observed RTT over the connection. No other RTT measurement is stable. For example, both the instantanious and the long-term-averaged RTT measurement creates a positive feedback situation in the core calculation (i.e. NOT stable if used alone). The minimum RTT measurement cannot be used alone without making the algorithm non-responsive to changes in available channel bandwidth, but it can be used to anchor and stabilize the algorithm and that is what TCP Vegas does.
The problem with New Reno is that most routers do not drop packets until their queues are already mostly full... far too late (i.e. the RTTs have already gone out of control by the time intermediate nodes finally decide to start dropping packets), and even running something like RED is only a hack to try to drop packets earlier, before it is too late. Anything that depends on ALL intermediate nodes physically dropping packets according to a TCP-optimized algorithm to generate implied feedback for TCP is a stupid and unnecessary approach in my view.
TCP Vegas is very similar to the algorithm I implemented in FreeBSD (the net.inet.tcp.inflight_enable sysctl). Both attempt to calculate the available channel bandwidth and adjust a TCP connection to fit the available bandwidth. Both have the same problem in that calculating the channel bandwidth depends on calculating the bandwidth-delay product which depends on a stable RTT, and the RTT is *NOT* stable when a channel is near or at its rated bandwidth. This is why both TCP Vegas and the algorithm I implemented in FreeBSD use the minimum observed RTT as a basis for the bandwidth-delay product calculation rather then the currently observed RTT or the long-term-averaged RTT (neither of which is stable if used alone). Both Vegas and the algorithm implemented in FreeBSD can still handle changes in available channel bandwidth within a reasonable range, but it isn't perfect because both must still be anchored using the only stable measurement available (the minimum observed RTT), and it is not possible to make it perfect due to the extreme instability of nearly all other measurements both the TCP server and TCP client could make during a connection.
NewReno's "wait for intermediate nodes to drop packets" method of congestion control is *COMPLETELY* broken. The only reason it works at all is because most TCP connections use fairly small advertised windows. When you use large advertised windows everything blows up. TCP Vegas and the FreeBSD algorithm can handle large advertised windows without blowing up.
It should be interesting to see what the FAST group comes up with, but I think they don't quite understand the extreme instabilities of the calculations being made. TCP Vegas does a fairly good job as does the algorithm in FreeBSD (both using the minimum observed RTT as an anchor in the calculations). Neither is perfect, but finding something better that manages to remain stable over a wide range of situations is not going to be a walk in the park.
Also, keep in mind that the so-called 200MBits of maximum bandwidth really only means 'full duplex', i.e. 100MBits in both directions simultaniously, not 200MBits in one direction. And even cheap 100BaseT switches are single-chip solutions with 5Gbit or better backplanes (being all on a single chip) and can do that no sweat.
I would go as far as to say, at least for in-home use, it's far better to invest in the slower and cheaper 802.11b WIFI gear and spend the money you save on wiring your house with 100BaseT, because regardless of the speed of the WIFI gear a hardline is always going to be an order of magnitude more responsive and far more reliable. I have netbooted machines on both hardlines and WIFI and I can say that rather definitively.
That is where 802.11g is. Only fools and the rich are buying it right now. I'll consider it a year or two after the standard has been laid in stone, because that is how long it is going to take for the various vendors to get onto the right track and for competition to push pricing down to reasonable levels. Buying into 802.11g now is a waste of time and money.
Even now 802.11b is barely up to the task, and vendors have had plenty of time to clean up their buggy firmware. I have 801.11b bridges that crash when running at the edge of their range, that can't auto-speed reliable, and base stations that can't transparently pass DHCP through (amoung other horrors). I'd rather the vendors fix all the problems with their existing offerings before they go running off into a new nirvana of buggy high speed devices that only work reliably at distances of less then 50 feet.
-Matt
And what is the media used in the backup box? A cheap removable IDE drive. Stickem or not, if worst came to worst the media is still far more recoverable (and I've never had to resort to a recovery service, so the cost is obviously low even if it does happen occassionally). I plan on upgrading the backup box to use a cheap IDE RAID controller in a few weeks, mainly so I can expand the storage and stage out the drives. Nothing expensive or fancy.
Problem solved.
Your time zone preference can be set on a shell-by-shell basis or process-by-process basis using the TZ environment variable. The system has a default preference that is typically
Programs can choose to use whatever timezone they wish independant of any preference. It just so happens that cron defaults to using the system local time preference but nothing prevents you from changing that if you don't like it. In fact, many cron's allow you to set the time zone you want to specify your jobs in on a user-by-user basis. So if cron's skipping around is bothering you, just switch it to GMT (1).
(note 1: well, it's either GMT or UTC, I forget which. There are subtle differences)
That said, the only time I use film any more is in extreme low light situations and even then I usually don't bother if I can get the equivalent with a long-exposure on my G2.
My Canon G2 Tests
-Matt
So while it is true that you tend to need to tune FreeBSD a bit more in an extreme environment, what you get out of it is far better stability and far more consistency under load. And *THAT* is why people use FreeBSD in those environments.
In anycase, I can see how this view happened. Earlier versions of FreeBSD were definitely overly conservative in regards to disk layout and system resources. But that's old news. It isn't the case anymore and hasn't been for quite some time.
-Matt
Similar tricks can be done with ports through the use of a R+W exported /usr/ports but I personally use a method that only requires a read-only /usr/ports export. It's really simple: On your master machine make /usr/ports/distfiles a softlink to /usr/ports.distfiles, mkdir the local /usr/ports.distfiles (on all the boxes), and in /etc/make.conf (on all the boxes) set WRKDIRPREFIX to a local filesystem with enough space. Then you can simply NFS export /usr/ports to your other boxes. To avoid downloading the distfile multiple times you can leave /usr/ports/distfiles alone and export that (read-only for safety), then simply build the port on the master server (no need to install it) and the distfiles will be there for the clients.
That coupled with a nightly cvsup on the server and every single box you have will have access to the latest and greatest with no effort at all.
-Matt
Now the complication: you cannot simply create a resonent wave to cancel out the slower components at point X because you do not know what those slower components are at point X (they haven't arrived yet). But since the signal itself knows (quantum mechanically speaking), you can use reflections of the signal itself, at near resonence, to cancel out portions of itself which have not yet arrived. Confused yet? The result is that the cancelation gives the whole signal 'a push'. This cancelation effect appears to move faster then the speed of light because it is canceling a wave that has not yet arrived. This is the phase velocity they are talking about I think. but it is only using information that has traveled at the speed of light (quantum mechanically speaking the universe only needs the leading edge of the attenuated signal to know the whole signal), so there is no way this technology could be used to actually achieve FTL data transfer.
This is for real, a number of universities have been working on it for years. How useful it winds up being in the end is a matter of opinion, though.
-Matt
-Matt
Just for the hell of it I ran the same benchmarks on one of my test boxes (FreeBSD running -current). The performance basically comes down to how much write latency you are willing to endure... the longer the latency, the better the benchmark results for the first two tests.
So, for example, with the (conservative) system defaults I only got around 250 trans/sec for mixed creations with the first postmark test, because the system doesn't allow more then around 18MB of dirty buffers to build up before it starts forcing the data out, and also does not allow large sequential blocks of dirty data to sit around. When I bump up the allowance to 80MB and turn off full-block write_behind the trans rate went up to 2776/sec. I got similar characteristics for the second test as well. Unfortunately I have only one 7200 rpm hard drive on this box so I couldn't repeat the third test in any meaningful way (which is a measure mostly of disk bandwidth).
In anycase, the point is clear, and the authors even mention it by suggesting that the ext3 write-back mode should only be used with NVRAM. Still, I don't think they realize that their RedHat box likely isn't even *writing* the data to the disk/NVRAM until it absolutely has to, so arbitrarily delaying writes for what is supposed to be a mail system is not a good evaluation of performance. Postmark does not fsync() any of the operations it tests whereas any real mail system worth its salt does, and even with three drives striped together this would put a big crimp on the reported numbers unless you have a whole lot of NVRAM in the RAID controller.
I do not believe RedHat does the write-behind optimization that FreeBSD does. This optimization exists specifically to maximize sequential performance without blowing up system caches (vs just accumulating dirty buffers). But while this optimization is good in most production situations it also typically screws up non-sequential benchmark numbers by actually doing I/O to the drive when the benchmark results depend on I/O not having been done :-).
Last thought. Note that the FreeBSD 4.6 release has a performance issue with non-truncated file overwrites (not appends, but the 'rewrite without truncation' type of operation). This was fixed post-release in -stable.
-Matt
You guys crack me up some times.
I'll lay it out. Obviously Google is not storing the master copy of the full multi-terrabyte database in ram, but they are certainly storing as big a chunk in ram as they can, and the cost model ought to be easy for anyone to understand if you sit down and think about it.
Consider the cost difference between the following EQUAL amounts of hard disk storage:
* A 160GB IDE drive
* A 160GB SCSI drive
* Four 40GB drives in an external RAID system
* The cost of a small medium-performance RAID
system.
* The cost of a larger high-performance RAID
system scaleability to a terrabyte.
* The cost of an *EXTREMELY* high performance RAID
system scaleability to multiple terrabytes.
Now consider the cost of building, say, a 40 terrabyte data store (lets not worry about backups for this experiment). If you build it out of a bunch of huge SCSI drives connected to a bunch of PC's it can be fairly cheap. But if you build out of, say, high performance EMC arrays it could cost millions of dollars more to get the same theoretical performance.
So when you consider the cost of storage, you always have to consider the cost of the PERFORMANCE you want to get out of that storage. All the Google CEO is saying is that, Doh! It's a hellofalot cheaper to improve the performance aspects of the system by buying DRAM in a distributed-PC environment in order to be able to avoid having to purchase extremely-high performance (and extremely expensive) disk subsystems. The cost of purchasing the DRAM to make up for the lower-performing disk subsystem is actually LOWER then the cost of purchasing an equivalent higher-performance disk subsystem.
The same is true in the ISP world. When RAM was expensive we had to rely on big whopping HD systems to scale machines up. But when RAM became cheap it turned out that you could simply throw in a very high density drive with 1/4 the performance that four smaller drives would give you, and the operating system's RAM cache would take care of the problem. Suddenly we no longer needed to purchase big whopping disk arrays.
Think about it.
-Matt
Find an old Commodore Pet computer on the junk heap somewhere. Turn it on, make sure the monitor still works, and extract the TTL digital input wire from the internal monitor cable while leaving the remaining wires connected. You can then use this (and ground) to probe TTL signals up to around 7MHz :-)
Alternatively you can go to CompUsa and spend $60 on a cheap oscilloscope.
-Matt