Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #162948 > unrolled thread

Re: IBM's 96 column punch card (was System/3)?

Back to article view | Back to alt.folklore.computers

Contents

  Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-26 11:42 +0000
    Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-04-26 14:36 -0500
      Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-27 00:42 +0200
        Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-04-27 13:48 +0000
          Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-28 08:41 +0200
      Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-27 12:40 +0000
        Re: IBM's 96 column punch card (was System/3)? Andy Burns <feb2017-usenet@adslpipe.co.uk> - 2016-04-27 14:51 +0100
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-04-27 22:27 -0500
            Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-28 12:06 +0000
              Re: IBM's 96 column punch card (was System/3)? Quadibloc <jsavard@ecn.ab.ca> - 2016-04-28 07:49 -0700
                Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-28 17:03 +0000
                  Re: IBM's 96 column punch card (was System/3)? "Osmium" <r124c4u102@comcast.net> - 2016-04-28 12:18 -0500
                    Re: IBM's 96 column punch card (was System/3)? Anne & Lynn Wheeler <lynn@garlic.com> - 2016-04-28 11:19 -0700
                      Re: IBM's 96 column punch card (was System/3)? hancock4@bbs.cpcn.com - 2016-04-28 14:19 -0700
                  Re: IBM's 96 column punch card (was System/3)? "Charles Richmond" <numerist@aquaporin4.com> - 2016-04-29 16:47 -0500
                Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-29 12:18 +0000
              Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-04-28 17:03 +0000
                Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-04-29 12:18 +0000
                  Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-04-29 15:14 +0200
              Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:09 +0000
        Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-04-27 22:19 -0500
          Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:21 +0000
        Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-03 14:03 +0000
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-03 13:58 -0500
          Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-03 14:22 -0500
            Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-04 20:21 +0000
          tape drives [was Re: IBM's 96 column punch card (was System/3)?] Rich Alderson <news@alderson.users.panix.com> - 2016-05-03 15:39 -0400
          Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-04 13:02 +0000
            Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-05-04 11:45 -0500
              Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-05 01:13 +0200
                Re: IBM's 96 column punch card (was System/3)? Jon Elson <jmelson@wustl.edu> - 2016-05-05 14:25 -0500
                  Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-05 19:34 +0000
                    Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-06 13:28 +0000
                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-06 14:39 +0000
                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-06 14:41 +0000
                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-07 13:14 +0000
                          Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-05-07 16:47 +0000
                            Re: IBM's 96 column punch card (was System/3)? Andrew Swallow <am.swallow@btopenworld.com> - 2016-05-07 23:30 +0100
                              Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-08 13:08 +0000
                          Re: IBM's 96 column punch card (was System/3)? Jon Elson <elson@pico-systems.com> - 2016-05-07 16:07 -0500
                          Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-07 21:23 +0000
                            Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-08 13:08 +0000
                              Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-09 15:13 +0000
                                Re: IBM's 96 column punch card (was System/3)? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-05-09 17:05 +0000
                                  Re: IBM's 96 column punch card (was System/3)? pechter@pechter.net (William Pechter) - 2016-05-09 22:41 +0000
                                    Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-10 12:01 +0200
                                      Re: IBM's 96 column punch card (was System/3)? Peter Flass <peter_flass@yahoo.com> - 2016-05-10 06:42 -0400
                                    Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-10 12:34 +0000
                                      Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-10 13:05 +0000
                                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-11 12:18 +0000
                                          Re: IBM's 96 column punch card (was System/3)? scott@slp53.sl.home (Scott Lurndal) - 2016-05-11 13:27 +0000
                                      Re: IBM's 96 column punch card (was System/3)? Morten Reistad <first@last.name.invalid> - 2016-05-10 15:53 +0200
                                        Re: IBM's 96 column punch card (was System/3)? jmfbahciv <See.above@aol.com> - 2016-05-11 12:18 +0000
                                Re: IBM's 96 column punch card (was System/3)? "Simo" <dhy287@gmail.com> - 2016-05-10 04:56 +1000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#163019

jmfbahciv wrote:


> DEC never managed to manufacture a good tape drive.  My favorite was the
> TU70s followed by TU40s.  Everything else hung a PDP-10 was crap.  I
> always wondered why we couldn't make a good tape drive since we did make
> the best tape mechanism called DECtapes (the real DECtapes, not those
> others they called DECtapes to make them look good).
Well, of course, DEC never made a 1/2" tape drive.  Most of them were 
Pertec, I think.  The TU-45 was a Pertec T-9000, and that was a pretty good 
drive.  I have an actual Pertec-label one here.  Never had a single problem 
with it.

The TU-77/78 was a Pertec T-1000, a very awesome drive, but maybe not well 
packaged by DEC.  Or, maybe Pertec sent it over to DEC before they really 
got the environmental (read : cooling) issues under control.  Once those 
thermal retrofits got installed, it was a fine drive, too.

Another really good drive was the CDC Keystone.  (92181 for 800/1600 and 
92185 for 1600/6250).  Built like a tank, and if KISS is a good motto for 
you, there probably has never been a mechanically simpler drive.  Two 
motors, two air bearings and a head.

Jon

[toc] | [prev] | [next] | [standalone]

#163139

In article <KradnduSZOSnHLzKnZ2dnUU7-SnNnZ2d@giganews.com>,
Jon Elson  <elson@pico-systems.com> wrote:
>jmfbahciv wrote:
>
>
>> DEC never managed to manufacture a good tape drive.  My favorite was the
>> TU70s followed by TU40s.  Everything else hung a PDP-10 was crap.  I
>> always wondered why we couldn't make a good tape drive since we did make
>> the best tape mechanism called DECtapes (the real DECtapes, not those
>> others they called DECtapes to make them look good).
>Well, of course, DEC never made a 1/2" tape drive.  Most of them were 
>Pertec, I think.  The TU-45 was a Pertec T-9000, and that was a pretty good 
>drive.  I have an actual Pertec-label one here.  Never had a single problem 
>with it.
>
>The TU-77/78 was a Pertec T-1000, a very awesome drive, but maybe not well 
>packaged by DEC.  Or, maybe Pertec sent it over to DEC before they really 
>got the environmental (read : cooling) issues under control.  Once those 
>thermal retrofits got installed, it was a fine drive, too.
>

The real shame of it was it was to be a big seller at DEC... who took some of
the miserable TU45's in as a stop gap. There were supposed to be a couple of
hundred for the LCG folks who needed something faster than the TU10/TU16/TE16
45 ips drives and cheaper than the STC drives.

The TU45's were so bad Pertec pulled the engineers off the TU77 delaying it
while they had to fully rework the TU45's.  As far as the TU77/78 drives --
they were very good with a great track record.  All the TU78's had the cooling
heat exchangers.  I had TU77's without them and never had problems but they
were only used for backup and loading of tapes on Vaxes.  I think the use
was heavier in the 36 bit mainframe area.

>Another really good drive was the CDC Keystone.  (92181 for 800/1600 and 
>92185 for 1600/6250).  Built like a tank, and if KISS is a good motto for 
>you, there probably has never been a mechanically simpler drive.  Two 
>motors, two air bearings and a head.
>
>Jon

I did a training course on Keystone HW maintenance at Concurrent Computer
after DEC...  My favorite drive was the HP 88780A we used at Pyramid.

Fun to boot and run OSx Unix from a tape based Read-Only image on the tape for 
install and recovery.

Available in Pertec and SCSI interfaces and even in a tri-density version.
Reliable as you could be.

Built like a tank... but HP was always known for pretty good hardware back
in the day.


Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[toc] | [prev] | [next] | [standalone]

#163137

In article <PM00053176BCF5B066@aca4129f.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Jon Elson wrote:
>
>DEC never managed to manufacture a good tape drive.  My favorite was the
>TU70s followed by TU40s.  Everything else hung a PDP-10 was crap.  I always
>wondered why we couldn't make a good tape drive since we did make the
>best tape mechanism called DECtapes (the real DECtapes, not those others
>they called DECtapes to make them look good).

The TU70's were STC's if I remember correctly.
Who did the TU40s?

The TU45's were 100% crap Pertec.  The TU77's and TU/TA78's were the best
drives Pertec ever made for DEC.  I never had any problems with them
in the Field, but I started working on them in '82... so they may have
had early problems.

The TU45's looked like converted tension arm drives reworked with split
(at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the sound
of misloads when I think of them.

I actually liked the TU80's... (MPI division of CDC IIRC)...
They were slow but pretty reliable.

A TU7x made a decent backup/load device for a Vax... I think the KL's needed
something more robust.
>
>
>If you wanted reliable magtapes, it required lots of good, working gear.
>
>/BAH


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[toc] | [prev] | [next] | [standalone]

#163146

William Pechter wrote:



> 
> The TU45's were 100% crap Pertec.
I think this was a Pertec T9000 drive.  We had one with the Pertec label, 
and it was a dead solid drive, NEVER had the slightest problem with it.
Now, possibly DEC sold an earlier version, or did not get some important 
update that our drive did have.  I do know from the manual there were a 
WHOLE lot of ECOs in the prints.

> The TU77's and TU/TA78's were the best
> drives Pertec ever made for DEC.  I never had any problems with them
> in the Field, but I started working on them in '82... so they may have
> had early problems.
> 
Otyher than heating issues, it seemed to be a really good drive.  Once the 
bearing air cooling system and bearing air filters were put in, ours was a 
great drive, too.  I just wish we'd gotten a TU78, would have saved a LOT of 
time doing backups.
> The TU45's looked like converted tension arm drives reworked with split
> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
> sound of misloads when I think of them.
> 
I still have our Pertec T9000, and I can say that those misloads were so 
rare, I'd say maybe twice a year, and always with a tape that had some kind 
of damage.
> I actually liked the TU80's... (MPI division of CDC IIRC)...
> They were slow but pretty reliable.
> 
That was probably a 92181.  A totally awesome streaming drive.  I have some 
92185's here.  VERY well done.

Jon

[toc] | [prev] | [next] | [standalone]

#163150

William Pechter wrote:


> 
> The TU45's looked like converted tension arm drives reworked with split
> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
> sound of misloads when I think of them.
> 
The Pertec T9000 had AC tachometers in the rollers where the tape off the 
reels went into the vacuum columns.  The drive circuitry (all analog, I 
think) compared the off-reel velocity with the capstan velocity to figure 
out how much torque to apply to the reel motors.  I understand the 
adjustment of that was tricky, but I have never had to touch it on my drive 
(either when we had it at work or when I used it at home).

Jon

[toc] | [prev] | [next] | [standalone]

#163240

In article <EIedncKjBPrsZ7XKnZ2dnUU7-YHNnZ2d@giganews.com>,
Jon Elson  <jmelson@wustl.edu> wrote:
>William Pechter wrote:
>
>
>> 
>> The TU45's looked like converted tension arm drives reworked with split
>> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
>> sound of misloads when I think of them.
>> 
>The Pertec T9000 had AC tachometers in the rollers where the tape off the 
>reels went into the vacuum columns.  The drive circuitry (all analog, I 
>think) compared the off-reel velocity with the capstan velocity to figure 
>out how much torque to apply to the reel motors.  I understand the 
>adjustment of that was tricky, but I have never had to touch it on my drive 
>(either when we had it at work or when I used it at home).
>
>Jon

I just took a google search and yup... It's the T9000. They seemed ok for
medium to light use... on the larger VAX disk farms they didn't cut it for
speed or reliability.

Was doing the SUP/SUS TUP/TUS adjustments on two of the four bastards
at Fort Monmouth's CENTACS 11/780 when the damned boards overheated and
caught fire.  Not a great design -- when you do the recommended adjustment
and the thing gets so hot the resistors flame up...

One good thing about the Ada Language System project -- they upgraded the
dual 11/780 setup to TU77's...or was it 78's...

Bill
Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[toc] | [prev] | [next] | [standalone]

#163152 — tape drives [was Re: IBM's 96 column punch card (was System/3)?]

pechter@pechter.net (William Pechter) writes:

> A TU7x made a decent backup/load device for a Vax... I think the KL's needed
> something more robust.

We used TU72s at UChicago Comp Center; it was decades before I found out how
close I had come to a PDP-8/A (in the TX02 controller).

We had a single TU45 at LOTS (Stanford), and a bank of TU78s.  (The TU45 was
complete garbage.)

We used TU78s at XKL, and at LCM on the same KL-10.  They've always been robust
enough for real work.

The Toad-1 had 2 drives qualified for it; I always preferred the M4data 9914,
which is what we use at the museum even now, if we need real reel tape for 36
bits.  (Unisys V380 and Xerox Sigma have their own drives.)

Mostly we emulate tapes these days.

-- 
Rich Alderson                                   news@alderson.users.panix.com
    the russet leaves of an autumn oak/inspire once again the failed poet/
    to take up his pen/and essay to place his meagre words upon the page...

[toc] | [prev] | [next] | [standalone]

#163195

William Pechter wrote:
> In article <PM00053176BCF5B066@aca4129f.ipt.aol.com>,
> jmfbahciv  <See.above@aol.com> wrote:
>>Jon Elson wrote:
>>
>>DEC never managed to manufacture a good tape drive.  My favorite was the
>>TU70s followed by TU40s.  Everything else hung a PDP-10 was crap.  I always
>>wondered why we couldn't make a good tape drive since we did make the
>>best tape mechanism called DECtapes (the real DECtapes, not those others
>>they called DECtapes to make them look good).
>
> The TU70's were STC's if I remember correctly.
> Who did the TU40s?

I don't remember.

>
> The TU45's were 100% crap Pertec.  The TU77's and TU/TA78's were the best
> drives Pertec ever made for DEC.  I never had any problems with them
> in the Field, but I started working on them in '82... so they may have
> had early problems.
>
> The TU45's looked like converted tension arm drives reworked with split
> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
sound
> of misloads when I think of them.

There was one, and only one, person in Marlboro who could convince a
TU45 to load; he was the operations supervisor.  To do backups of the
KS10, operators shut down the machine and moved the packs to a system
up for timesharing and then did the backups.

>
> I actually liked the TU80's... (MPI division of CDC IIRC)...
> They were slow but pretty reliable.

Those were after my time.  I don't think they were hooked up
to a PDP-10.

>
> A TU7x made a decent backup/load device for a Vax... I think the KL's needed
> something more robust.

The software was not good either; I never found out why.

/BAH

[toc] | [prev] | [next] | [standalone]

#163212

jmfbahciv wrote:

> William Pechter wrote:

>>
>> The TU45's were 100% crap Pertec.  The TU77's and TU/TA78's were the best
>> drives Pertec ever made for DEC.  I never had any problems with them
>> in the Field, but I started working on them in '82... so they may have
>> had early problems.
>>
>> The TU45's looked like converted tension arm drives reworked with split
>> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
> sound
>> of misloads when I think of them.
> 
> There was one, and only one, person in Marlboro who could convince a
> TU45 to load; he was the operations supervisor.  To do backups of the
> KS10, operators shut down the machine and moved the packs to a system
> up for timesharing and then did the backups.
> 
I'm pretty sure the TU45 was a DEC-labeled Pertec T9000 drive.  We had one 
of the Pertec-badged versions, and it was a very reliable unit.  I admit, 
this is a sample of one, but we ran tens of thousands of reels of tape 
through it.  It was used as our main data drive on an 11/45 for a number of 
years, and we read thousands of tapes of raw data to analyze per year.  We 
also used it for backup/restore, but the main use was reading data tapes.  
It was later moved to a VAX 11/780 for a few years.  I have the drive here 
at home, and last time I used it (a LONG time ago) it still worked fine.

I can understand if the tension on the tape bobbled for even a millisecond 
then the tape loop could flip sideways and dump the column, but the only 
time ours ever did that was due to wrinkles in the tape.

We did have a spring-arm Pertec drive before the T9000, and that one was 
nowhere as good at tape handling.  The tape would slip on the capstan roller 
and do all sorts of undesirable stuff.

Jon

[toc] | [prev] | [next] | [standalone]

#163246

In article <U_WdnRb804CJurfKnZ2dnUU7-eHNnZ2d@giganews.com>,
Jon Elson  <elson@pico-systems.com> wrote:
>jmfbahciv wrote:
>
>> William Pechter wrote:
>
>>>
>>> The TU45's were 100% crap Pertec.  The TU77's and TU/TA78's were the best
>>> drives Pertec ever made for DEC.  I never had any problems with them
>>> in the Field, but I started working on them in '82... so they may have
>>> had early problems.
>>>
>>> The TU45's looked like converted tension arm drives reworked with split
>>> (at this point I want to say spit) Vacuum columns.  Ugh.  Still hear the
>> sound
>>> of misloads when I think of them.
>> 
>> There was one, and only one, person in Marlboro who could convince a
>> TU45 to load; he was the operations supervisor.  To do backups of the
>> KS10, operators shut down the machine and moved the packs to a system
>> up for timesharing and then did the backups.
>> 
>I'm pretty sure the TU45 was a DEC-labeled Pertec T9000 drive.  We had one 
>of the Pertec-badged versions, and it was a very reliable unit.  I admit, 
>this is a sample of one, but we ran tens of thousands of reels of tape 
>through it.  It was used as our main data drive on an 11/45 for a number of 
>years, and we read thousands of tapes of raw data to analyze per year.  We 
>also used it for backup/restore, but the main use was reading data tapes.  
>It was later moved to a VAX 11/780 for a few years.  I have the drive here 
>at home, and last time I used it (a LONG time ago) it still worked fine.
>
>I can understand if the tension on the tape bobbled for even a millisecond 
>then the tape loop could flip sideways and dump the column, but the only 
>time ours ever did that was due to wrinkles in the tape.

Getting the TU45 to stream, and keeping it there, was essetial to both
performance and reliability. It was quite usable when it got to stream
through a tape.

I wrote a simple program to use large blocks and keep the drive busy
on read, and giving it lots of memory to read into when reading. 

I made a program that forked, and had one process use two quarters of
the moby that changed betweed the master and child as it was read, and
the non-active one was fed to a fortran/cobol/pascal program. 

I got the processing time of the statistics tapes from ~35 minutes down
to <3, plus the rewind time. Since they had a few thousand of those in
a very high prestige project I got all the time on the machine after
hours for my effort. And the TU45 lasted a LOT longer between services.

The local field service had some magic they did with that drive, with
some magical master tape and an oscilliscope. Probably some analogue
calibration and adjustments.

>We did have a spring-arm Pertec drive before the T9000, and that one was 
>nowhere as good at tape handling.  The tape would slip on the capstan roller 
>and do all sorts of undesirable stuff.

-- mrr

[toc] | [prev] | [next] | [standalone]

#163281

Morten Reistad wrote:


> Getting the TU45 to stream, and keeping it there, was essetial to both
> performance and reliability. It was quite usable when it got to stream
> through a tape.
> 
I wrote a program that was essentially equivalent to Linux's dd command, it 
would stream from disk to tape or vice-versa, and as long as you had error-
free media it was fantastic.  I think I only used this on the 11/45 with the 
spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't hit 
any errors, it could dump or restore an entire 40 MB Calcomp disk in a 
little over 10 minutes.

> The local field service had some magic they did with that drive, with
> some magical master tape and an oscilliscope. Probably some analogue
> calibration and adjustments.
> 
The T9000 / TU45 was all analog, but the master tape would be used for head 
skew adjustment - only really needed for 800 BPI.

Jon

[toc] | [prev] | [next] | [standalone]

#163283

Jon Elson <jmelson@wustl.edu> writes:
>Morten Reistad wrote:
>
>
>> Getting the TU45 to stream, and keeping it there, was essetial to both
>> performance and reliability. It was quite usable when it got to stream
>> through a tape.
>> 
>I wrote a program that was essentially equivalent to Linux's dd command, it 
>would stream from disk to tape or vice-versa, and as long as you had error-
>free media it was fantastic.  I think I only used this on the 11/45 with the 
>spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't hit 
>any errors, it could dump or restore an entire 40 MB Calcomp disk in a 
>little over 10 minutes.

I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).  They
actually had a higher transfer rate than one of our models of disk drive,
which I found to my consternation when I tested a double-buffering algorithm
that didn't bother to wait for write completion (under the assumption that
disks were always faster than tape :-).

[toc] | [prev] | [next] | [standalone]

#163297

Scott Lurndal wrote:
> Jon Elson <jmelson@wustl.edu> writes:
>>Morten Reistad wrote:
>>
>>
>>> Getting the TU45 to stream, and keeping it there, was essetial to both
>>> performance and reliability. It was quite usable when it got to stream
>>> through a tape.
>>>
>>I wrote a program that was essentially equivalent to Linux's dd command, it
>>would stream from disk to tape or vice-versa, and as long as you had error-
>>free media it was fantastic.  I think I only used this on the 11/45 with the
>>spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't hit
>>any errors, it could dump or restore an entire 40 MB Calcomp disk in a
>>little over 10 minutes.
>
> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).  They
> actually had a higher transfer rate than one of our models of disk drive,
> which I found to my consternation when I tested a double-buffering algorithm
> that didn't bother to wait for write completion (under the assumption that
> disks were always faster than tape :-).

<GRIN>  Computers always did that to developers.  What did you do to "fix"
it?

/BAH

[toc] | [prev] | [next] | [standalone]

#163299

jmfbahciv <See.above@aol.com> writes:
>Scott Lurndal wrote:
>> Jon Elson <jmelson@wustl.edu> writes:
>>>Morten Reistad wrote:
>>>
>>>
>>>> Getting the TU45 to stream, and keeping it there, was essetial to both
>>>> performance and reliability. It was quite usable when it got to stream
>>>> through a tape.
>>>>
>>>I wrote a program that was essentially equivalent to Linux's dd command, it
>>>would stream from disk to tape or vice-versa, and as long as you had error-
>>>free media it was fantastic.  I think I only used this on the 11/45 with the
>>>spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't hit
>>>any errors, it could dump or restore an entire 40 MB Calcomp disk in a
>>>little over 10 minutes.
>>
>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).  They
>> actually had a higher transfer rate than one of our models of disk drive,
>> which I found to my consternation when I tested a double-buffering algorithm
>> that didn't bother to wait for write completion (under the assumption that
>> disks were always faster than tape :-).
>
><GRIN>  Computers always did that to developers.  What did you do to "fix"
>it?
>
>/BAH

[toc] | [prev] | [next] | [standalone]

#163300

jmfbahciv <See.above@aol.com> writes:
>Scott Lurndal wrote:
>> Jon Elson <jmelson@wustl.edu> writes:
>>>Morten Reistad wrote:
>>>
>>>
>>>> Getting the TU45 to stream, and keeping it there, was essetial to both
>>>> performance and reliability. It was quite usable when it got to stream
>>>> through a tape.
>>>>
>>>I wrote a program that was essentially equivalent to Linux's dd command, it
>>>would stream from disk to tape or vice-versa, and as long as you had error-
>>>free media it was fantastic.  I think I only used this on the 11/45 with the
>>>spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't hit
>>>any errors, it could dump or restore an entire 40 MB Calcomp disk in a
>>>little over 10 minutes.
>>
>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).  They
>> actually had a higher transfer rate than one of our models of disk drive,
>> which I found to my consternation when I tested a double-buffering algorithm
>> that didn't bother to wait for write completion (under the assumption that
>> disks were always faster than tape :-).
>
><GRIN>  Computers always did that to developers.  What did you do to "fix"
>it?

Waited for the disk write to complete before starting the next
magtape read into the buffer.

[toc] | [prev] | [next] | [standalone]

#163340

Scott Lurndal wrote:
> jmfbahciv <See.above@aol.com> writes:
>>Scott Lurndal wrote:
>>> Jon Elson <jmelson@wustl.edu> writes:
>>>>Morten Reistad wrote:
>>>>
>>>>
>>>>> Getting the TU45 to stream, and keeping it there, was essetial to both
>>>>> performance and reliability. It was quite usable when it got to stream
>>>>> through a tape.
>>>>>
>>>>I wrote a program that was essentially equivalent to Linux's dd command,
it
>>>>would stream from disk to tape or vice-versa, and as long as you had
error-
>>>>free media it was fantastic.  I think I only used this on the 11/45 with
the
>>>>spring-arm drive, not the T9000 drive with vacuum columns.  If it didn't
hit
>>>>any errors, it could dump or restore an entire 40 MB Calcomp disk in a
>>>>little over 10 minutes.
>>>
>>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).  They
>>> actually had a higher transfer rate than one of our models of disk drive,
>>> which I found to my consternation when I tested a double-buffering
algorithm
>>> that didn't bother to wait for write completion (under the assumption that
>>> disks were always faster than tape :-).
>>
>><GRIN>  Computers always did that to developers.  What did you do to "fix"
>>it?
>
> Waited for the disk write to complete before starting the next
> magtape read into the buffer.

Would having a buffer ring be too complicated?

/BAH

[toc] | [prev] | [next] | [standalone]

#163349

On 2016-05-07, jmfbahciv <See.above@aol.com> wrote:

> Scott Lurndal wrote:
>
>> jmfbahciv <See.above@aol.com> writes:
>>
>>> Scott Lurndal wrote:
>>>
>>>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).
>>>> They actually had a higher transfer rate than one of our models
>>>> of disk drive, which I found to my consternation when I tested a
>>>> double-buffering algorithm that didn't bother to wait for write
>>>> completion (under the assumption that disks were always faster
>>>> than tape :-).
>>>
>>> <GRIN>  Computers always did that to developers.  What did you do
>>> to "fix" it?
>>
>> Waited for the disk write to complete before starting the next
>> magtape read into the buffer.
>
> Would having a buffer ring be too complicated?

Probably not, if it was considered necessary.  I know that things are
different in these days of powerful hardware and bloatware, but at the
time few people would write a bunch of code that they figured they could
do without.

Besides, back then the concept of tapes being faster than disks was
a bit of a mind-bender.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#163373

On 07/05/2016 17:47, Charlie Gibbs wrote:
> On 2016-05-07, jmfbahciv <See.above@aol.com> wrote:
>
>> Scott Lurndal wrote:
>>
>>> jmfbahciv <See.above@aol.com> writes:
>>>
>>>> Scott Lurndal wrote:
>>>>
>>>>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).
>>>>> They actually had a higher transfer rate than one of our models
>>>>> of disk drive, which I found to my consternation when I tested a
>>>>> double-buffering algorithm that didn't bother to wait for write
>>>>> completion (under the assumption that disks were always faster
>>>>> than tape :-).
>>>>
>>>> <GRIN>  Computers always did that to developers.  What did you do
>>>> to "fix" it?
>>>
>>> Waited for the disk write to complete before starting the next
>>> magtape read into the buffer.
>>
>> Would having a buffer ring be too complicated?
>
> Probably not, if it was considered necessary.  I know that things are
> different in these days of powerful hardware and bloatware, but at the
> time few people would write a bunch of code that they figured they could
> do without.
>
> Besides, back then the concept of tapes being faster than disks was
> a bit of a mind-bender.
>
I have also seen tapes being faster than disks on an ICL 1900. On time 
sharing systems the CPU can be busy when the disk is free and the disk 
can have other users.

[toc] | [prev] | [next] | [standalone]

#163409

Andrew Swallow wrote:
> On 07/05/2016 17:47, Charlie Gibbs wrote:
>> On 2016-05-07, jmfbahciv <See.above@aol.com> wrote:
>>
>>> Scott Lurndal wrote:
>>>
>>>> jmfbahciv <See.above@aol.com> writes:
>>>>
>>>>> Scott Lurndal wrote:
>>>>>
>>>>>> I quite enjoyed using our 200IPS GCR drives (rebadged STC, IIRC).
>>>>>> They actually had a higher transfer rate than one of our models
>>>>>> of disk drive, which I found to my consternation when I tested a
>>>>>> double-buffering algorithm that didn't bother to wait for write
>>>>>> completion (under the assumption that disks were always faster
>>>>>> than tape :-).
>>>>>
>>>>> <GRIN>  Computers always did that to developers.  What did you do
>>>>> to "fix" it?
>>>>
>>>> Waited for the disk write to complete before starting the next
>>>> magtape read into the buffer.
>>>
>>> Would having a buffer ring be too complicated?
>>
>> Probably not, if it was considered necessary.  I know that things are
>> different in these days of powerful hardware and bloatware, but at the
>> time few people would write a bunch of code that they figured they could
>> do without.
>>
>> Besides, back then the concept of tapes being faster than disks was
>> a bit of a mind-bender.
>>
> I have also seen tapes being faster than disks on an ICL 1900. On time
> sharing systems the CPU can be busy when the disk is free and the disk
> can have other users.

Right.  The buffer filler and emptier can continue to work while the
CPU is busy with other things.  But that requires multiple buffer rings.

/BAH

[toc] | [prev] | [next] | [standalone]

#163365

jmfbahciv wrote:


> 
> Would having a buffer ring be too complicated?
Well, the one I did was on a PDP-11, and to run that in real mode, you only 
had enough memory for a couple buffers.  So, I did it with just two buffers.
Since this program took over the whole system and accessed the disk and tape 
controllers directly, I didn't want to try to learn how to use the memory 
management, too.

Jon

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web