test-drb March 2002

test-drb@ccmp.vtda.org

292 participants
932 discussions

by dhquebbeman＠theestopinalgroup.com

> The liklihood is that Compaq will be dismantled as a result, and that, in > itself seems a decent enough reason for the merger. Oh well. Never liked them, even though they ran my software at their Houston distribution center (I guess they were our largest client). -dq

23 years, 1 month

VAX 6460 being slow, IO bottlenecks and SMP woes ...

by ajp166＠bellatlantic.net

From: Eric Smith <eric(a)brouhaha.com> >Not counting an eight-hour power failure, one of my PC-based servers >has had under two minutes of unscheduled downtime in seven years of >24x7 operation. That's better than 99.9999%. > >Of course, it's not running Windows. I have winder boxen that do that as servers. As desktops forget it, Word dies and takes the OS at times. Never seen that on VMS. >I don't know what systems those were, but my first 486 PCI system >routinely got sustained PCI throughput of over 15 MB/second, between >disk, ethernet, and display. and the processor was doing something useful? >Even many ISA bus systems could sustain over 4 MB/second. Yes, it could. Shame the CPU was idle or doing just the block move. I've seen Qbus systems (PDP-11) sustain levels like that but, the CPU was useful. PCs, and their busses didn't allow for concurrentcy of operations especially ISA. Allison

23 years, 1 month

ZX-TEAM meeting and Webcam

by ajp166＠bellatlantic.net

From: Glen Goodwin <acme_ent(a)bellsouth.net> >> From: Fred Cisin (XenoSoft) <cisin(a)xenosoft.com> > >> Is there a Linux port for the ZX81? No but, you might run UZI unix on it. Oh< you want a Zx81 sim? Why? the real thing is far more fun. Allison

23 years, 1 month

Text-based PONG!

by bpope＠wordstock.com

Check out http://www.karber.net/textbased/pong/ where you can play Pong with *ANY* browser, including Lynx! Enjoy!, Bryan P.S. I did not have anything to do with the creation of this masterpiece.

23 years, 1 month

VAX 6460 being slow, IO bottlenecks and SMP woes ...

by ajp166＠bellatlantic.net

From: Gunther Schadow <gunther(a)aurora.regenstrief.org> >Yes, so, let's suppose that ULTRIX didn't take full advantage >of the hardware, but nothing can get me back to using VMS. That's >for sure. Ultrix was not nearly as well developed as VMS for multiple CPU and cluster configs. Available user performance on a 6k system with decent disks was very high under VMS but under ultrix is was a less appealing system. I'd used an identical pair while at DEC with both ultrix and VMS and the ultrix system was a bit doggy even at lighter user loads (no one liked it). Comparing it to a 486... no contest with a pot load of users. the i486 does not have the system robustness and IO capability. Allison

23 years, 1 month

Plexus minicomputer?

by vcf＠siconic.com

Anyone know about Plexus minicomputers? I am going to pick one up soon. I'm told it's about 3-4 feet high by 2 feet wide by 5-6 feet deep, and heavy. -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org * Old computing resources for business and academia at www.VintageTech.com *

23 years, 1 month

list changes

by timwa＠snowgoons.fsnet.co.uk

Pete Turnbull wrote: > On Mar 20, 12:59, David Woyciesjes wrote: >> From: Jay West >>> B) I also like the 'self-policing' idea of making posts to the list >>> from non-subscribers get a subject tag of [OL] or something like that. >> >> Another good idea. >> >> Can't the system compare the From or ReplyTo field against the >> subscriber list, and take action from there? >> > Good point. There are almost certainly people on the list who've > subscribed from a different address than the one they have the mail sent > to. Not insurmountable, but it does need consideraton. While we're on the subject, I do think the [OL] idea is a good one, but I just wanted to add my tuppence worth on the subject... The address I post from isn't always the same as the one I read it from; I tend to choose the address to post from (work or home) as appropriate to the content of the message... If we go with the tagging off-list posts, it would be nice if there was a way of registering additional 'posting addresses' as well as the subscription address. Not essential, of course, but would be handy (would be more essential if we got to the stage of actively blocking off-list posts.) Incidentally, I'm all in favour of the blocking HTML, by the way... Cheers, Tim. -- Tim Walls at home in Croydon - Reply to tim(a)snowgoons.fsnet.co.uk

23 years, 1 month

VAX 6460 being slow, IO bottlenecks and SMP woes ...

by gunther＠aurora.regenstrief.org

It is very contemplative to sit in the basement, room filled with big iron and lots of blower and disk noise, and watch the system creep ahead compiling stuff. I remember those old days back in, say, 1994 when I sat there on a i486/33 watching GCC compile (and those *endless* runs of all the fix-include stuff.) What surprizes me is that the feeling on a 1989 vintage 6-processor million-dollar VAX isn't very different! I expected it to be faster with that. So I looked at statistics. Nothing paged out (0.5 GB of RAM), but looks like the system is heavily I/O bound and I/O is quite slow. I even distributed disk load over 3 RA90, though all on the same controller, but at least that's a KDM70, directly on the XMI bus. Still, disk access seems just a bit on the slow side. Why? All terminal I/O went through the Ethernet, which I thought was a DEBNT but is reported to me as a DEBNA. Anyway, that's just the few lines of text that are being logged as make creeps forward with its job. Looked at cpustat (we're on Ultrix 4.5 BTW), where you can see the load on the CPUs. Sorry, no "screenshot" here, but in short it lists 6 CPU's and the load on each. 5 of them tend to be 97% idle and CPU#1 is 75% idle. CPU #1 gets bombarded with all interrupt requests while the others get none of that. Unfortunately I couldn't figure out how one can see process to CPU allocation. I suppose that each process runs in a single thread on one CPU every time it is active. Since the making and the cc-ing is a sequential thing writing temporary files to disk, I suppose that the 5 idle processors have nothing to do while CPU#1 takes all the burden of the compiling task plus all other system interrupts (essentiall all I/O.) So, that's kind of not optimal. I suppose, once I have my first GCC built I should use the -pipe option to avoid temporary files with the hope that the two ends of each pipe would then be allocated to two different CPUs. That should then speed up the process a lot, basically could stream cpp on CPU#1 to cc1 on CPU#2 to as on CPU#3 right through. I hope. That is, if UNIX domain sockets (i.e. pipes) are implemented so as to not require any hardware IO. I *hope* this is simply done by CPU#1 entering kernel with an mbuf and CPU#2 entering kernel shortly thereafter reading that mbuf, so only memory should be involved. It's interesting. At some time soon, may be early this summer, I'll give a VAX party where one of the highlights will be a race between my i486/33 and the 6460 in compiling something, there we can see if it's really just my perception that the 6460 is kind of slow for the price, even measured by past standards. Another thing that made me wonder is that writing to the TU81+ on KLESI-B showed its signs of I/O bottlenecks. When I just did # tar cvb 20 -f /dev/nrmt0h /usr5/gcc-2.7.2 the tape would write block by block in staccato and would not stream. The TU81 is still nice even in block mode, not that endless back and forth of the TK50 or any other cassette media that I have seen operating, it's a fast staccato tatatatatatata, you gotta see this! Only if I used my dd buffering trick with # tar cvb 20 -f - /usr5/gcc-2.7.2 |dd ibs=2048000 of=/dev/nrmt0h obs=10240 would it stream over larger sections. But the slightest disk read activity would cause a little pause to the tape transport. First I thought I should be rearranging my cards on the VAXBI busses, but then I remembered that the disks are on XMI directly. So, a simple RA90 read through KDM70 on XML is just not fast enough in order to keep the VAXBI - KLESIB - TU81+ streaming. Are the RA90 disks so slow? Or may be it is Ultrix' bad way of using the multipe CPUs again, i.e., they still handle all the work through one single CPU#1 while the others are chatting idly? Does NetBSD do a better job with SMP? Would it use one CPU for the disk IO and another CPU for the KLESI-B IO with shared memory buffers in the middle? May be not if I used just one process to both read from disk and write to tape (like tar only), but with the pipe, tar | dd it should do it and that should allow me to use a smaller ibs for dd, AND have real streaming write to the tape. Or is SMP on NetBSD/VAX still a sub-optimal hack? When I attended BSDcon 2002 in San Francisco few weeks ago, it seemed like all the BSDs would go different ways about SMP. I liked what Jason announced about NetBSD, like IO being handled without memory data copies, and the kernel actually shrinking in size. I would hope that all BSD/SMP efforts nowadays seek to allow true load sharing between the CPUs and not shedule IRQs to only one and not hog that one primary I/O CPU with *all* processes that have any I/O to do. And I sure hope that it will be natural for pipelined processes to operate on different CPUs. Right? regards, -Gunther -- Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistant Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org

23 years, 1 month

ZX-TEAM meeting and Webcam

by acme_ent＠bellsouth.net

> From: Ben Franchuk <bfranchuk(a)jetnet.ab.ca> > I kind of thought the ZX81 was a VW Bug :) Some would say more like a Morris Minor. And BTW the Bug makes a lousy doorstop ;>) Glen 0/0

23 years, 1 month

DSQD Drives (Was: RE: Diags/Boot image for Altos 580)

by acme_ent＠bellsouth.net

> From: Joe <rigdonj(a)cfl.rr.com> > Buy? Who said anything about buying??? I can get all the drives that I > want for next to nothing. If I do pay for a PC, it's only about $1 each. Joe, if you ever run out of sources (fat chance) I've got mountains of 5.25" drives you can have for five cents a pound. Hell, I've got over 20 of 'em here at home! >Most of the times that I use a 1.2M > drive to read/write other formats, it fails. Even when it doesn't fail the > copies don't hold up well. I could NEVER read my SB 180 disks (QD) in a 1.2 > Mb drive. In fact, I finally pulled the 1.2 Mb drive out of my main PC and > put a 360k drive back into it since the 5 1/4" drive was used almost > entirely for reading/writing old disks. Yup, I did the same thing on my main box, and getting rid of that 1.2MB drive has really simplified my life. Glen 0/0

23 years, 1 month

← Newer
1
...
30
31
32
33
34
35
36
...
94
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb March 2002