Thu, 22 Jul 2010

----- Forwarded message from Kragen Javier Sitaker <kragen at canonical.org> -----

From: Kragen Javier Sitaker <kragen at canonical.org>
To: Jamie McCarthy <jamie at mccarthy.vg>
Subject: Re: Could a vacuum tube computer be fast?

On Thu, Jul 22, 2010 at 07:25:48AM -0400, Jamie McCarthy wrote:
> > I'm proposing they should have built *smaller* ones in
> > which the tubes switched more often, and I don't know why they
> > didn't.
> 
> Hardware flaws? It was my understanding that tube reliability was
> *the* major flaw in vacuum-tube computers. Hardware failures in
> Eniac's 17,000 tubes gave it uptimes measured in hours.

That would have militated against running the tubes so slowly and using
so many of them. If you can use half the tubes for the same
computational power, then the machine will run for twice as long. This
was one of the major advantages of the LGP-30, with 113 vacuum tubes,
over the ENIAC with its 17 000. (It's not quite a fair comparison. Stan
Frankel, the LGP-30's designer, had the advantage of experience
programming the ENIAC, and more than 1400 semiconductor diodes.)

Also, if you can get more computational power out of the same tubes,
your uptime won't change, but you'll be able to complete bigger
calculations before the next crash.

All of the subsequent tube machines were an order of magnitude smaller
than ENIAC. ENIAC was just badly designed, that's all.

> Economic pressures? What were the bottlenecks of the era? Did they
> have many programs that were complex enough that runtime was the most
> important consideration?

Both runtime and memory size were major limiting factors. It wasn't
until the late 1950s that the software problem really became known.

> Heat dissipation problems? How did the wattage per liter, and energy
> efficiency, change with smaller tubes? Tubes emit most of their heat
> as radiation I would imagine, so the modern solution (conduct heat
> away and force convection) might not be an effective offset as
> densities increase.

That's an interesting question, and Dave Long brought it up on
kragen-discuss.

Do you mind if I forward your email there, too?

Kragen

----- End forwarded message -----

----- Forwarded message from Jamie McCarthy <jamie at mccarthy.vg> -----

Subject: Re: Could a vacuum tube computer be fast?
From: Jamie McCarthy <jamie at mccarthy.vg>
To: Kragen Javier Sitaker <kragen at canonical.org>

> I'm proposing they should have built *smaller* ones in
> which the tubes switched more often, and I don't know why they
> didn't.

Hardware flaws? It was my understanding that tube reliability was *the* major flaw in vacuum-tube computers. Hardware failures in Eniac's 17,000 tubes gave it uptimes measured in hours.

Economic pressures? What were the bottlenecks of the era? Did they have many programs that were complex enough that runtime was the most important consideration?

Heat dissipation problems? How did the wattage per liter, and energy efficiency, change with smaller tubes? Tubes emit most of their heat as radiation I would imagine, so the modern solution (conduct heat away and force convection) might not be an effective offset as densities increase.

--
 Jamie McCarthy
 jamiekzoo at gmail.com
 jamie at mccarthy.vg
 269-267-2008

----- End forwarded message -----

If I've done the math correctly, a single 955 acorn tube runs almost  
a watt for the heater alone, and then around 3/4 of a watt for the  
anode current.

Could it be that no one built small fast tube computers because their  
busbars would have melted down in sparkling, coruscating displays of  
incandescent brilliance ?

-Dave

Sat, 17 Jul 2010

tractor tires are another example of herringbone "gears".

this implies they should track much better forward than in reverse.

i'll have to try the experiment next time i have a chance to drive one.

-Dave

:: :: ::
I ha-n-uhuera gärn wenn's stinkt
nach Schwii nach Schoof nach Ross nach Rind
I ha-n-uhuera gärn wenn's blinkt
48 zoll felgä: chromed out pimp

----- Forwarded message from Seth David Schoen <schoen at loyalty.org> -----

From: Seth David Schoen <schoen at loyalty.org>
To: Kragen Javier Sitaker <kragen at canonical.org>
Subject: Re: multicast file transfer advertisement: bccpi.py and bccpo.py
X-Modulation: 8/VSB Is Not A Crime

Kragen Javier Sitaker writes:

> On Sat, Jul 17, 2010 at 07:30:17AM -0700, Seth David Schoen wrote:
> > Kragen Javier Sitaker writes:
> > 
> > > This is a pair of Python programs to use to copy files around on the
> > > LAN. The receiver uses IP multicast on the LAN to advertise its
> > > interest in the file; the sender then connects to it via TCP to send
> > > it.
> > 
> > Have you seen npush and npoll, an earlier implementation of this idea
> > in C?  It was really convenient, actually.  We shipped them on
> > some versions of LNX-BBC.
> 
> I haven't! Can I forward your message to kragen-discuss?

Sure!  Take a look at

http://www.fefe.de/ncp/

for npush and npoll.

-- 
Seth David Schoen <schoen at loyalty.org> | Qué empresa fácil no pensar en
     http://www.loyalty.org/~schoen/   | un tigre, reflexioné.
     http://vitanuova.loyalty.org/     |            -- Borges, El Zahir

----- End forwarded message -----