- From: nemo/Joel N. Weber II <devnull@gnu.ai.mit.edu>
- Date: Tue, 22 Apr 1997 18:55:40 -0400
- To: Ross_Patterson@ns.reston.vmd.sterling.com
- Cc: http-wg@cuckoo.hpl.hp.com
Date: Tue, 22 Apr 97 18:17:14 EDT From: "Ross Patterson" <Ross_Patterson@ns.reston.vmd.sterling.com> While I understand and sympathize with the issue here (I've already got too many clocks in my home, I don't need more to reset twice a year!), I find it suprising that TCP can be implemented on a system that has no timing facilities. For that matter, don't many (most?) embedded systems have a real-time kernel, with a timer-based dispatcher? Or am I mistaking a timer for a time-of-day-and-date clock? Yes, there's a difference between a timer designed to help with mutlitasking and a timer which tells you the time of day. Assuming a completely standalone server which has no battery backup, which boots using DHCP and tftp or whatever (or has all its software in ROM--though then it still needs at least rarp), there's generally no need to have a clock to run a soda machine or a thermometer. Admittedly, a soda machine which logs times people get sodas is quite interesting. So is a thermomenter which generates nice graphs showing time. Admittedly, if you're going to all this trouble, you could ask another machine on the network for the time; but I bet there are other applications where you don't care about the time. (What about routers? Some of them can be configured from the web; but why would a router care about wall clock time?)
Received on Tuesday, 22 April 1997 20:57:00 UTC