Hello,
yes, I know this is defenitely no new issue (maybe its none to you
anyway), since I found posts about this dating from 1998: the
jiffies counter rolls over after approx. 497 days uptime, which
causes the uptime to roll over as well, and seems to cause some
other irretation in the system itself (my pc speaker starting
beeping constantely...)
I noticed this on a couple of servers just having had 500 days of
uptime, and so I starting looking at the kernel code and played
around with a tiny jiffie manipulating kernel module. Since jiffies
is unsigned long (being 32 bits wide on x86) and counts 1/100th
seconds, it can only hold about 497 days...
This seems to be true for both 2.2 and 2.4, at least for 2.2.16 and
2.4.17, which I tested...
The uptime thingy could IMHO be solved with some kind of rollover
counter, and I'm currently digging into that area... Stuff like a pc
speaker driver going wild bothers me a bit more...
Could anybody perhaps tell me why he/she doesn't consider this a
problem? And is there a fundamental problem with solving this in
general? (I do see a problem with defining jiffies long long on x86,
because it might break a lot of things and probably wouldnt perform
as often as jiffies is touched... And you might sense I haven't
been into kernel hacking much...)
My first post here, sorry :)
Regards,
Oliver
> counter, and I'm currently digging into that area... Stuff like a pc
> speaker driver going wild bothers me a bit more...
Fix the speaker driver I guess is the answer. It shouldnt have done that.
> Could anybody perhaps tell me why he/she doesn't consider this a
> problem? And is there a fundamental problem with solving this in
> general? (I do see a problem with defining jiffies long long on x86,
> because it might break a lot of things and probably wouldnt perform
> as often as jiffies is touched... And you might sense I haven't
> been into kernel hacking much...)
Counting in long long is expensive and the drivers are meant to all use
roll over safe compares
On Mon, 18 Feb 2002, Alan Cox wrote:
> > counter, and I'm currently digging into that area... Stuff like a pc
> > speaker driver going wild bothers me a bit more...
>
> Fix the speaker driver I guess is the answer. It shouldnt have done that.
Well, yeah.. So if its just the speaker driver I might sleep better
now :)
> > Could anybody perhaps tell me why he/she doesn't consider this a
> > problem? And is there a fundamental problem with solving this in
> > general? (I do see a problem with defining jiffies long long on x86,
> > because it might break a lot of things and probably wouldnt perform
> > as often as jiffies is touched... And you might sense I haven't
> > been into kernel hacking much...)
>
> Counting in long long is expensive and the drivers are meant to all use
> roll over safe compares
Yes, that's what I thought of, long long being too expensive. And
since jiffies doesn't seem to have a problem with rolling over, I
might try to hack the uptime-releated code a bit for myself... If
nobody isn't going like "DONT! THAT'S A VERY BAD IDEA FOR THIS AND
THIS REASON!" :)
Thanks
Oliver
On Mon, 18 Feb 2002, Oliver Hillmann wrote:
> Hello,
>
> yes, I know this is defenitely no new issue (maybe its none to you
> anyway), since I found posts about this dating from 1998: the
> jiffies counter rolls over after approx. 497 days uptime, which
> causes the uptime to roll over as well, and seems to cause some
> other irretation in the system itself (my pc speaker starting
> beeping constantely...)
See
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-47/0736.html
for a patch.
I intend to submit this for 2.4.19pre after some more testing and
feedback.
Also note that several patches for jiffies rollover bugs have gone into
2.4.18pre, maybe one of them fixes the speaker driver.
Tim
Alan Cox wrote:
>>counter, and I'm currently digging into that area... Stuff like a pc
>>speaker driver going wild bothers me a bit more...
>>
>
> Fix the speaker driver I guess is the answer. It shouldnt have done that.
>
>
>>Could anybody perhaps tell me why he/she doesn't consider this a
>>problem? And is there a fundamental problem with solving this in
>>general? (I do see a problem with defining jiffies long long on x86,
>>because it might break a lot of things and probably wouldnt perform
>>as often as jiffies is touched... And you might sense I haven't
>>been into kernel hacking much...)
>>
>
> Counting in long long is expensive and the drivers are meant to all use
> roll over safe compares
I wonder, is it more expensive to write all drivers to handle the
wraps than to take the long long increment hit? The increment is
once every 10 miliseconds, right? That is not too often, all things
considered...
Maybe the non-atomicity of the long long increment is the problem?
Does this problem still exist on 64-bit machines?
THanks,
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit? The increment is
Total cost of handling it right - 0 clocks. Its simply about maths order
and sign
> Maybe the non-atomicity of the long long increment is the problem?
A big one yes.
> Does this problem still exist on 64-bit machines?
Not in the same way - you'll need a lot of years before you worry about it.
On Mon, 18 Feb 2002, Ben Greear wrote:
> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit? The increment is
> once every 10 miliseconds, right? That is not too often, all things
> considered...
This is just a matter of getting the signed/unsigned declarations right in
comparisons. (time_before and time_after macros were introduced to aid
here, hint!)
No overhead is involved here.
Actually, quite a few bug fixes in this area went into 2.4.18pre, with
some more to come in 2.4.19pre.
>
> Maybe the non-atomicity of the long long increment is the problem?
Yes.
> Does this problem still exist on 64-bit machines?
>
No.
> THanks,
> Ben
Tim
Many will be grateful if this finally allows
the correct uptime to be generated after
497 days - my busy mail/dns servers now
have 611 days uptime, but to outsiders it
appears they only have 114 days uptime,
and there are bizarre items in the process
table, e.g. programs that were apparently
started in the year 2003...
Joe
Tim Schmielau wrote:
>On Mon, 18 Feb 2002, Oliver Hillmann wrote:
>
>>Hello,
>>
>>yes, I know this is defenitely no new issue (maybe its none to you
>>anyway), since I found posts about this dating from 1998: the
>>jiffies counter rolls over after approx. 497 days uptime, which
>>causes the uptime to roll over as well, and seems to cause some
>>other irretation in the system itself (my pc speaker starting
>>beeping constantely...)
>>
>
>See
>http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-47/0736.html
>for a patch.
>I intend to submit this for 2.4.19pre after some more testing and
>feedback.
>
>Also note that several patches for jiffies rollover bugs have gone into
>2.4.18pre, maybe one of them fixes the speaker driver.
>
>Tim
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, Feb 18, 2002 at 10:31:34PM +0000, Alan Cox wrote:
> > I wonder, is it more expensive to write all drivers to handle the
> > wraps than to take the long long increment hit? The increment is
>
> Total cost of handling it right - 0 clocks. Its simply about maths order
> and sign
$ uname -a ; uptime
Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
6:22pm up 425 days, 1:35, 3 users, load average: 0.10, 0.05, 0.01
This server is pretty remote and hard to reach, and not sure to reboot
properly unattended - are there predictions about how well 2.2.18 will
survive jiffy wraparound?
Would you consider it worth rebooting for? By the way, this is our second
most important production server, I'm exceedingly pleased with the
stability. We've abused it no end.
Thanks.
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc
> Would you consider it worth rebooting for? By the way, this is our second
> most important production server, I'm exceedingly pleased with the
> stability. We've abused it no end.
I would schedule maintenance for it at the point it wraps. Its not the most
tested code path in 2.2
FWIW our servers that wrapped around
almost 4 months ago have been running
fine, no real problems - Red Hat 6.1 with
2.2.17-pre4 kernel.
Joe
bert hubert wrote:
>On Mon, Feb 18, 2002 at 10:31:34PM +0000, Alan Cox wrote:
>
>>>I wonder, is it more expensive to write all drivers to handle the
>>>wraps than to take the long long increment hit? The increment is
>>>
>>Total cost of handling it right - 0 clocks. Its simply about maths order
>>and sign
>>
>
>$ uname -a ; uptime
>Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
> 6:22pm up 425 days, 1:35, 3 users, load average: 0.10, 0.05, 0.01
>
>This server is pretty remote and hard to reach, and not sure to reboot
>properly unattended - are there predictions about how well 2.2.18 will
>survive jiffy wraparound?
>
>Would you consider it worth rebooting for? By the way, this is our second
>most important production server, I'm exceedingly pleased with the
>stability. We've abused it no end.
>
>Thanks.
>
>Regards,
>
>bert
>
On Mon, 18 Feb 2002, Ben Greear wrote:
> I wonder, is it more expensive to write all drivers to handle the
> wraps than to take the long long increment hit? The increment is
> once every 10 miliseconds, right? That is not too often, all things
> considered...
If you are willing to code in assembler instead of C you can do better,
at least on x86. You just need to do a 32 bit increment on the LS word,
and if you get a carry you can incr the MS word.
> Maybe the non-atomicity of the long long increment is the problem?
I doubt it, the problem is that the software which expects jiffies is
not all going to work well 64 bit. I think that's more the issue, and why
Alan et al are fixing it piecemeal, I don't think there's some magic fix
they're missing.
> Does this problem still exist on 64-bit machines?
Absolutely. But not as often ;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
* bert hubert ([email protected]) wrote:
> $ uname -a ; uptime
> Linux newyork-1 2.2.18 #3 Mon Dec 11 15:57:33 EST 2000 i686 unknown
> 6:22pm up 425 days, 1:35, 3 users, load average: 0.10, 0.05, 0.01
Linux ns2 2.2.16 #1 Sun Jul 30 21:57:38 EDT 2000 i386 unknown
19:55:29 up 1 day, 15:06, 1 user, load average: 0.00, 0.03, 0.00
-rw-r--r-- 1 root root 1569 Oct 8 2000 /var/log/dmesg
No problems here so far, just wrapped. Processes seemed to all handle
it okay though ps now shows some things started in 2003.. :)
> This server is pretty remote and hard to reach, and not sure to reboot
> properly unattended - are there predictions about how well 2.2.18 will
> survive jiffy wraparound?
It's honestly not good to not know how to reboot a box unattended. :)
> Would you consider it worth rebooting for? By the way, this is our second
> most important production server, I'm exceedingly pleased with the
> stability. We've abused it no end.
I'd certainly make arrangements to have it rebooted if necessary. If
rebooting is a huge problem then I'd say just have someone on hand in
case you *have* to.
Stephen
Once upon a time, Alan Cox <[email protected]> said:
>I would schedule maintenance for it at the point it wraps. Its not the most
>tested code path in 2.2
I've got a couple of servers running 2.2 that have long rolled over (one
206 days ago and the other 314 days ago) without any trouble. Another
six months and the second one will roll over a second time. We're
looking at moving them to a new location, and I'm trying to figure out
how to splice an UPS in the power cord. :-)
--
Chris Adams <[email protected]>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
On Mon, 18 Feb 2002, Stephen Frost wrote:
> Linux ns2 2.2.16 #1 Sun Jul 30 21:57:38 EDT 2000 i386 unknown
> 19:55:29 up 1 day, 15:06, 1 user, load average: 0.00, 0.03, 0.00
>
> -rw-r--r-- 1 root root 1569 Oct 8 2000 /var/log/dmesg
>
> No problems here so far, just wrapped. Processes seemed to all handle
> it okay though ps now shows some things started in 2003.. :)
[root@adelphi /root]# uptime
4:26am up 273 days, 1:34, 17 users, load average: 0.15, 0.18, 0.14
ie it wrapped 273 days ago. :) 734 days. it's the standard RH 2.2.16
kernel from RH6.1.
hanvt noticed any funnies whatsoever. (except init and some other
long running procs seem to have a start time that varies whenever you
run ps, which isnt right.)
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
It's a recession when your neighbour loses his job; it's a depression
when you lose yours.
-- Harry S. Truman
Bill Davidsen wrote:
>
> On Mon, 18 Feb 2002, Ben Greear wrote:
>
> > I wonder, is it more expensive to write all drivers to handle the
> > wraps than to take the long long increment hit? The increment is
> > once every 10 miliseconds, right? That is not too often, all things
> > considered...
>
> If you are willing to code in assembler instead of C you can do better,
> at least on x86. You just need to do a 32 bit increment on the LS word,
> and if you get a carry you can incr the MS word.
>
> > Maybe the non-atomicity of the long long increment is the problem?
>
> I doubt it, the problem is that the software which expects jiffies is
> not all going to work well 64 bit. I think that's more the issue, and why
> Alan et al are fixing it piecemeal, I don't think there's some magic fix
> they're missing.
>
> > Does this problem still exist on 64-bit machines?
>
> Absolutely. But not as often ;-)
Actually you will have a VERY hard time getting it to roll over. Issues
of your life time, not to mention the hardware's life time. 64 bits
makes a VERY large number and you are counting in 427 day increments.
Remember we have been counting seconds since 1970 in 32 bits and
rollover is still, most likely, beyond the capability of any machine
running today to get to. Now consider counting in 427 day increments
instead of seconds.
>
> --
> bill davidsen <[email protected]>
> CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
George [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
On Tue, Feb 19, 2002 at 12:55:22PM -0800, you [george anzinger] wrote:
> >
> > > Does this problem still exist on 64-bit machines?
> >
> > Absolutely. But not as often ;-)
>
> Actually you will have a VERY hard time getting it to roll over. Issues
> of your life time, not to mention the hardware's life time. 64 bits
> makes a VERY large number and you are counting in 427 day increments.
> Remember we have been counting seconds since 1970 in 32 bits and
> rollover is still, most likely, beyond the capability of any machine
> running today to get to. Now consider counting in 427 day increments
> instead of seconds.
48.5 day increments, not 497. On alpha and ia64 it's 1024 jiffies per
second.
Well, ok. Majority of the 64-bit archs seem to in fact use HZ=100:
asm-alpha/param.h:# define HZ 1024
asm-ia64/param.h:# define HZ 1024
asm-mips64/param.h:#define HZ 100
asm-ppc64/param.h:#define HZ 100
asm-s390x/param.h:#define HZ 100
asm-sparc64/param.h:#define HZ 100
asm-x86_64/param.h:#define HZ 100
-- v --
[email protected]
On Tue, 19 Feb 2002, george anzinger wrote:
> Bill Davidsen wrote:
> >
> > On Mon, 18 Feb 2002, Ben Greear wrote:
> > > Does this problem still exist on 64-bit machines?
> >
> > Absolutely. But not as often ;-)
>
> Actually you will have a VERY hard time getting it to roll over. Issues
> of your life time, not to mention the hardware's life time. 64 bits
> makes a VERY large number and you are counting in 427 day increments.
> Remember we have been counting seconds since 1970 in 32 bits and
> rollover is still, most likely, beyond the capability of any machine
> running today to get to. Now consider counting in 427 day increments
> instead of seconds.
Um, note the odd characters appended to my sentence ";-)" which means
"not serious here, look for joke, sarcasm, over or understatement.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Bill Davidsen wrote:
>
> On Tue, 19 Feb 2002, george anzinger wrote:
>
> > Bill Davidsen wrote:
> > >
> > > On Mon, 18 Feb 2002, Ben Greear wrote:
>
> > > > Does this problem still exist on 64-bit machines?
> > >
> > > Absolutely. But not as often ;-)
> >
> > Actually you will have a VERY hard time getting it to roll over. Issues
> > of your life time, not to mention the hardware's life time. 64 bits
> > makes a VERY large number and you are counting in 427 day increments.
> > Remember we have been counting seconds since 1970 in 32 bits and
> > rollover is still, most likely, beyond the capability of any machine
> > running today to get to. Now consider counting in 427 day increments
> > instead of seconds.
>
> Um, note the odd characters appended to my sentence ";-)" which means
> "not serious here, look for joke, sarcasm, over or understatement.
>
Ok, I guess I just got so impressed with the size of a 64-bit value that
I was overwhelmed. Consider, for example:
u64 i;
for (i = 1; i != 0; i++);
Now in theory this will count each possible number, but in practice the
machine will die long before it ever finishes.
--
George [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
On Wed, Feb 20, 2002 at 01:36:02PM +0200, Ville Herva wrote:
> asm-ia64/param.h:# define HZ 1024
> asm-x86_64/param.h:#define HZ 100
>
What's the difference between these two architectures? Intel 64bit
processor and AMD's upcoming 64bit processor?
Mike
On Wed, 20 Feb 2002, Mike Fedyk wrote:
> On Wed, Feb 20, 2002 at 01:36:02PM +0200, Ville Herva wrote:
> > asm-ia64/param.h:# define HZ 1024
> > asm-x86_64/param.h:#define HZ 100
>
> What's the difference between these two architectures? Intel 64bit
> processor and AMD's upcoming 64bit processor?
One is a 64 bit extension to a modern superscalar
architecture which has descended from 8 bit machines
over the ages.
The other is a 3-issue VLIW follow-up to the 2-issue
VLIW i860.
cheers,
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
On Wed, Feb 20, 2002 at 02:24:42PM -0300, Rik van Riel wrote:
> On Wed, 20 Feb 2002, Mike Fedyk wrote:
> > On Wed, Feb 20, 2002 at 01:36:02PM +0200, Ville Herva wrote:
> > > asm-ia64/param.h:# define HZ 1024
> > > asm-x86_64/param.h:#define HZ 100
> >
> > What's the difference between these two architectures? Intel 64bit
> > processor and AMD's upcoming 64bit processor?
>
> One is a 64 bit extension to a modern superscalar
> architecture which has descended from 8 bit machines
> over the ages.
>
> The other is a 3-issue VLIW follow-up to the 2-issue
> VLIW i860.
>
Oh, I didn't know that processor was used for more than printers, raid
controllers, and similar.
Anyone have an URL for this arch?
> cheers,
>
> Rik
Thanks,
Mike
> > On Wed, Feb 20, 2002 at 02:24:42PM -0300, Rik van Riel wrote:
> > > One is a 64 bit extension to a modern superscalar
> > > architecture which has descended from 8 bit machines
> > > over the ages.
> > >
> > > The other is a 3-issue VLIW follow-up to the 2-issue
> > > VLIW i860.
> >
> On Wed, 20 Feb 2002, Mike Fedyk wrote:
> > Oh, I didn't know that processor was used for more than printers, raid
> > controllers, and similar.
> >
> > Anyone have an URL for this arch?
>
On Wed, Feb 20, 2002 at 02:39:53PM -0300, Rik van Riel wrote:
> Intel has it well hidden from their front page, but you
> can find info here:
>
> http://www.intel.com/itanium/index.htm
>
Thanks,
Do you have an URL for the "3-issue VLIW follow-up to the 2-issue VLIW i860"
arch?
Mike
On Wed, 20 Feb 2002, Mike Fedyk wrote:
> On Wed, Feb 20, 2002 at 02:24:42PM -0300, Rik van Riel wrote:
> > On Wed, 20 Feb 2002, Mike Fedyk wrote:
> > > On Wed, Feb 20, 2002 at 01:36:02PM +0200, Ville Herva wrote:
> > > > asm-ia64/param.h:# define HZ 1024
> > > > asm-x86_64/param.h:#define HZ 100
> > >
> > > What's the difference between these two architectures? Intel 64bit
> > > processor and AMD's upcoming 64bit processor?
> >
> > One is a 64 bit extension to a modern superscalar
> > architecture which has descended from 8 bit machines
> > over the ages.
> >
> > The other is a 3-issue VLIW follow-up to the 2-issue
> > VLIW i860.
>
> Oh, I didn't know that processor was used for more than printers, raid
> controllers, and similar.
>
> Anyone have an URL for this arch?
Intel has it well hidden from their front page, but you
can find info here:
http://www.intel.com/itanium/index.htm
cheers,
Rik
--
Will hack the VM for food.
http://www.surriel.com/ http://distro.conectiva.com/
On Wednesday 20 February 2002 09:32 am, Mike Fedyk wrote:
> On Wed, Feb 20, 2002 at 02:24:42PM -0300, Rik van Riel wrote:
> > On Wed, 20 Feb 2002, Mike Fedyk wrote:
> > > On Wed, Feb 20, 2002 at 01:36:02PM +0200, Ville Herva wrote:
> > > > asm-ia64/param.h:# define HZ 1024
> > > > asm-x86_64/param.h:#define HZ 100
> > >
> > > What's the difference between these two architectures? Intel
> > > 64bit processor and AMD's upcoming 64bit processor?
> >
> > One is a 64 bit extension to a modern superscalar
> > architecture which has descended from 8 bit machines
> > over the ages.
> >
> > The other is a 3-issue VLIW follow-up to the 2-issue
> > VLIW i860.
>
> Oh, I didn't know that processor was used for more than printers,
> raid controllers, and similar.
IIRC, the i960 is the printer/controller arch, the i860 was the
(alleged) "cray-on-a-chip" number cruncher.
- Derek
>>>>> On Wed, 20 Feb 2002 14:24:42 -0300 (BRT), Rik van Riel <[email protected]> said:
Rik> On Wed, 20 Feb 2002, Mike Fedyk wrote:
>> What's the difference between these two architectures? Intel
>> 64bit processor and AMD's upcoming 64bit processor?
Rik> One is a 64 bit extension to a modern superscalar architecture
Rik> which has descended from 8 bit machines over the ages.
Interesting opinion.
Rik> The other is a 3-issue VLIW follow-up to the 2-issue VLIW i860.
There are some factual errors in this statement:
The ia64 _architecture_ places no limit on how many instructions can
be issued at a time. You could have an instruction group that's
thousands of instructions long which could all be executed in a single
cycle. Of course, realistic CPUs will bound the number of
instructions that can be issued in parallel. The Itanium and McKinley
_implementations_ of ia64 happen to issue up to 6 instructions at a
time, but other issue-widths are possible.
To the best of my knowledge, i860 had virtually no influence on ia64.
Cydrome's Cydra5 and Multiflow's TRACE did, as did PA-RISC.
Thanks,
--david
On Wed, 2002-02-20 at 12:24, Rik van Riel wrote:
> One is a 64 bit extension to a modern superscalar
> architecture which has descended from 8 bit machines
> over the ages.
>
> The other is a 3-issue VLIW follow-up to the 2-issue
> VLIW i860.
One nitpick ;-)
The IA-64 architecture does not limit the number of parallel
instructions. I believe IPF (current Itanium) has a limit of 2 bundles
per instruction group, and with 3 instructions per bundle, that gives a
max of 6 parallel instructions. This can change in the future, though.
I learned this in (no, he isn't paying me!) David's IA-64 Kernel book.
Robert Love
On Wed, 20 Feb 2002, Mike Fedyk wrote:
> On Wed, Feb 20, 2002 at 02:24:42PM -0300, Rik van Riel wrote:
> > The other is a 3-issue VLIW follow-up to the 2-issue
> > VLIW i860.
> Oh, I didn't know that processor was used for more than printers, raid
> controllers, and similar.
The 860 is a great processor, and was very fast compared to the
competition when introduced. Someone, Tektronics IIRC, built a really nice
little workstation based on that chip and SysV UNIX. Had the use of one
for a while, and it sure would do floating point!
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.