Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #162948 > unrolled thread
| Started by | jmfbahciv <See.above@aol.com> |
|---|---|
| First post | 2016-04-26 11:42 +0000 |
| Last post | 2016-05-10 04:56 +1000 |
| Articles | 14 on this page of 54 — 17 participants |
Back to article view | Back to alt.folklore.computers
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 3 of 3 — ← Prev page 1 2 [3]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-05-07 21:23 +0000 |
| Message-ID | <J1tXy.14037$Iu5.1173@fx06.iad> |
| In reply to | #163340 |
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? Would have been unnecessary, the double buffer algorithm used 100% of the device (disk /tape) bandwidth as it was. Adding more wouldn't have improved performance. This was used in the code that installed the operating system (COLDSTART) onto the boot media.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-05-08 13:08 +0000 |
| Message-ID | <PM000532544FAB5CDC@aca41104.ipt.aol.com> |
| In reply to | #163366 |
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? > > Would have been unnecessary, the double buffer algorithm used 100% of > the device (disk /tape) bandwidth as it was. Adding more wouldn't have > improved performance. > > This was used in the code that installed the operating system (COLDSTART) > onto the boot media. Ah, you were the only one on the system; that makes a differnce. I was trying to think of a way to not have to stop the magtape because getting it started again would take finagling (tapes move when idle). /BAH
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-05-09 15:13 +0000 |
| Message-ID | <4O1Yy.15985$6I7.4514@fx16.iad> |
| In reply to | #163411 |
jmfbahciv <See.above@aol.com> writes: >Scott Lurndal wrote: >>>Would having a buffer ring be too complicated? >> >> Would have been unnecessary, the double buffer algorithm used 100% of >> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >> improved performance. >> >> This was used in the code that installed the operating system (COLDSTART) >> onto the boot media. > >Ah, you were the only one on the system; that makes a differnce. I was >trying to think of a way to not have to stop the magtape because getting >it started again would take finagling (tapes move when idle). Tapes on the dozen models of tape drives I used never moved when idle.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2016-05-09 17:05 +0000 |
| Message-ID | <ngqg0v11dmi@news6.newsguy.com> |
| In reply to | #163470 |
On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: > jmfbahciv <See.above@aol.com> writes: > >> Scott Lurndal wrote: >> >>>> Would having a buffer ring be too complicated? >>> >>> Would have been unnecessary, the double buffer algorithm used 100% of >>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>> improved performance. >>> >>> This was used in the code that installed the operating system (COLDSTART) >>> onto the boot media. >> >> Ah, you were the only one on the system; that makes a differnce. I was >> trying to think of a way to not have to stop the magtape because getting >> it started again would take finagling (tapes move when idle). > > Tapes on the dozen models of tape drives I used never moved when idle. If they did, it was time to call in the CE. -- /~\ 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]
| From | pechter@pechter.net (William Pechter) |
|---|---|
| Date | 2016-05-09 22:41 +0000 |
| Message-ID | <ngr3mn$k75$2@pechter.eternal-september.org> |
| In reply to | #163475 |
In article <ngqg0v11dmi@news6.newsguy.com>, Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: > >> jmfbahciv <See.above@aol.com> writes: >> >>> Scott Lurndal wrote: >>> >>>>> Would having a buffer ring be too complicated? >>>> >>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>> improved performance. >>>> >>>> This was used in the code that installed the operating system (COLDSTART) >>>> onto the boot media. >>> >>> Ah, you were the only one on the system; that makes a differnce. I was >>> trying to think of a way to not have to stop the magtape because getting >>> it started again would take finagling (tapes move when idle). >> >> Tapes on the dozen models of tape drives I used never moved when idle. > >If they did, it was time to call in the CE. > >-- >/~\ 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! Only time tapes move when they're idle is when there's some tach or vacuum switch (or leak) issue making it move. Tape should be still when not reading/writing or rewinding. If not call the tech to bring the adjustment gear. 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]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-05-10 12:01 +0200 |
| Message-ID | <e5o80d-k6i.ln1@sambook.reistad.name> |
| In reply to | #163496 |
In article <ngr3mn$k75$2@pechter.eternal-september.org>, William Pechter <pechter@pechter.net> wrote: >In article <ngqg0v11dmi@news6.newsguy.com>, >Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >>On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: >> >>> jmfbahciv <See.above@aol.com> writes: >>> >>>> Scott Lurndal wrote: >>>> >>>>>> Would having a buffer ring be too complicated? >>>>> >>>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>>> improved performance. >>>>> >>>>> This was used in the code that installed the operating system (COLDSTART) >>>>> onto the boot media. >>>> >>>> Ah, you were the only one on the system; that makes a differnce. I was >>>> trying to think of a way to not have to stop the magtape because getting >>>> it started again would take finagling (tapes move when idle). >>> >>> Tapes on the dozen models of tape drives I used never moved when idle. >> >>If they did, it was time to call in the CE. >> >>-- >>/~\ 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! > > >Only time tapes move when they're idle is when there's some tach >or vacuum switch (or leak) issue making it move. Tape should be still >when not reading/writing or rewinding. If not call the tech to bring >the adjustment gear. Until the drive is worn. After a good number of years the vacuum column started leaking; just a little bit, on all of our Kennedy tape drives. They had a little movement of tape, but the electronics saw to it that there was no net movement of tape, just a little vibration, 2-3 mm at the most, when the tape was in the most worn part of the vacumm column. Since we used software that made the tapes stream as much as possible this was never a real problem. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-05-10 06:42 -0400 |
| Message-ID | <1669986028.484569653.202504.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #163504 |
Morten Reistad <first@last.name.invalid> wrote: > In article <ngr3mn$k75$2@pechter.eternal-september.org>, > William Pechter <pechter@pechter.net> wrote: >> In article <ngqg0v11dmi@news6.newsguy.com>, >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >>> On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: >>> >>>> jmfbahciv <See.above@aol.com> writes: >>>> >>>>> Scott Lurndal wrote: >>>>> >>>>>>> Would having a buffer ring be too complicated? >>>>>> >>>>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>>>> improved performance. >>>>>> >>>>>> This was used in the code that installed the operating system (COLDSTART) >>>>>> onto the boot media. >>>>> >>>>> Ah, you were the only one on the system; that makes a differnce. I was >>>>> trying to think of a way to not have to stop the magtape because getting >>>>> it started again would take finagling (tapes move when idle). >>>> >>>> Tapes on the dozen models of tape drives I used never moved when idle. >>> >>> If they did, it was time to call in the CE. >>> >>> -- >>> /~\ 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! >> >> >> Only time tapes move when they're idle is when there's some tach >> or vacuum switch (or leak) issue making it move. Tape should be still >> when not reading/writing or rewinding. If not call the tech to bring >> the adjustment gear. > > Until the drive is worn. After a good number of years the vacuum column > started leaking; just a little bit, on all of our Kennedy tape drives. > They had a little movement of tape, but the electronics saw to it that > there was no net movement of tape, just a little vibration, 2-3 mm > at the most, when the tape was in the most worn part of the vacumm > column. This is about what I observed. The tape gap would hide the problem in use. > > Since we used software that made the tapes stream as much as possible > this was never a real problem. > > -- mrr > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-05-10 12:34 +0000 |
| Message-ID | <PM0005327C08C91A0D@aca4069b.ipt.aol.com> |
| In reply to | #163496 |
William Pechter wrote: > In article <ngqg0v11dmi@news6.newsguy.com>, > Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >>On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: >> >>> jmfbahciv <See.above@aol.com> writes: >>> >>>> Scott Lurndal wrote: >>>> >>>>>> Would having a buffer ring be too complicated? >>>>> >>>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>>> improved performance. >>>>> >>>>> This was used in the code that installed the operating system (COLDSTART) >>>>> onto the boot media. >>>> >>>> Ah, you were the only one on the system; that makes a differnce. I was >>>> trying to think of a way to not have to stop the magtape because getting >>>> it started again would take finagling (tapes move when idle). >>> >>> Tapes on the dozen models of tape drives I used never moved when idle. >> >>If they did, it was time to call in the CE. > > Only time tapes move when they're idle is when there's some tach > or vacuum switch (or leak) issue making it move. Tape should be still > when not reading/writing or rewinding. If not call the tech to bring > the adjustment gear. Oh, there isn't any reading or writing going on. It just creeps a little bit. But everyone else is saying they never saw it. I wonder if it's because they weren't in a development lab. /BAH
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-05-10 13:05 +0000 |
| Message-ID | <h0lYy.16839$6k.9257@fx26.iad> |
| In reply to | #163510 |
jmfbahciv <See.above@aol.com> writes: >William Pechter wrote: >> Only time tapes move when they're idle is when there's some tach >> or vacuum switch (or leak) issue making it move. Tape should be still >> when not reading/writing or rewinding. If not call the tech to bring >> the adjustment gear. > >Oh, there isn't any reading or writing going on. It just creeps a little >bit. But everyone else is saying they never saw it. I wonder if >it's because they weren't in a development lab. A development lab is all that I was ever in, except for a handful of visits to customers. We had to support several generations of tape-drives in the MCP, so we had a wide range of old and new drives in the labs.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-05-11 12:18 +0000 |
| Message-ID | <PM0005328FFDABF37A@aca46c75.ipt.aol.com> |
| In reply to | #163516 |
Scott Lurndal wrote: > jmfbahciv <See.above@aol.com> writes: >>William Pechter wrote: > >>> Only time tapes move when they're idle is when there's some tach >>> or vacuum switch (or leak) issue making it move. Tape should be still >>> when not reading/writing or rewinding. If not call the tech to bring >>> the adjustment gear. >> >>Oh, there isn't any reading or writing going on. It just creeps a little >>bit. But everyone else is saying they never saw it. I wonder if >>it's because they weren't in a development lab. > > A development lab is all that I was ever in, except for a handful > of visits to customers. We had to support several generations of > tape-drives in the MCP, so we had a wide range of old and new drives > in the labs. The lab developed the hardware and then the software for the new gear? /BAH
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-05-11 13:27 +0000 |
| Message-ID | <GqGYy.30039$H_5.16171@fx18.iad> |
| In reply to | #163558 |
jmfbahciv <See.above@aol.com> writes:
>Scott Lurndal wrote:
>> jmfbahciv <See.above@aol.com> writes:
>>>William Pechter wrote:
>>
>>>> Only time tapes move when they're idle is when there's some tach
>>>> or vacuum switch (or leak) issue making it move. Tape should be still
>>>> when not reading/writing or rewinding. If not call the tech to bring
>>>> the adjustment gear.
>>>
>>>Oh, there isn't any reading or writing going on. It just creeps a little
>>>bit. But everyone else is saying they never saw it. I wonder if
>>>it's because they weren't in a development lab.
>>
>> A development lab is all that I was ever in, except for a handful
>> of visits to customers. We had to support several generations of
>> tape-drives in the MCP, so we had a wide range of old and new drives
>> in the labs.
>
>The lab developed the hardware and then the software for the new gear?
>
Yes. And supported all the old gear as well. Very large lab.
For those who don't use dialup, here's the 1980's[*] version
of the software development (operating system, compilers, networking, et alia) lab:
http://www.lurndal.org/images/unisys_pasadena.jpg
The hardware labs were in different locations in the building (the
subbasement had a B7900 installation used for CAD and simulation).
[*] After we had combined three separate cramped software labs from the
basement. When manufacturing was moved to Rancho Bernardo,
the manufacturing floor was remodeled into a large lab and
a bunch of offices around 1986.
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-05-10 15:53 +0200 |
| Message-ID | <sm590d-9li.ln1@sambook.reistad.name> |
| In reply to | #163510 |
In article <PM0005327C08C91A0D@aca4069b.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >William Pechter wrote: >> In article <ngqg0v11dmi@news6.newsguy.com>, >> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >>>On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: >>> >>>> jmfbahciv <See.above@aol.com> writes: >>>> >>>>> Scott Lurndal wrote: >>>>> >>>>>>> Would having a buffer ring be too complicated? >>>>>> >>>>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>>>> improved performance. >>>>>> >>>>>> This was used in the code that installed the operating system >(COLDSTART) >>>>>> onto the boot media. >>>>> >>>>> Ah, you were the only one on the system; that makes a differnce. I was >>>>> trying to think of a way to not have to stop the magtape because getting >>>>> it started again would take finagling (tapes move when idle). >>>> >>>> Tapes on the dozen models of tape drives I used never moved when idle. >>> >>>If they did, it was time to call in the CE. >> >> Only time tapes move when they're idle is when there's some tach >> or vacuum switch (or leak) issue making it move. Tape should be still >> when not reading/writing or rewinding. If not call the tech to bring >> the adjustment gear. > >Oh, there isn't any reading or writing going on. It just creeps a little >bit. But everyone else is saying they never saw it. I wonder if >it's because they weren't in a development lab. > >/BAH I saw it. But if the tape had any net movement we would call in field service and have the countermoves calibrated. If the tape drive was a Real Tape[1], and it was setup correctly it just vibrated a little bit. -- mrr [1] Which would exclude most of the DEC products.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-05-11 12:18 +0000 |
| Message-ID | <PM000532900B22FA14@aca46c75.ipt.aol.com> |
| In reply to | #163519 |
Morten Reistad wrote: > In article <PM0005327C08C91A0D@aca4069b.ipt.aol.com>, > jmfbahciv <See.above@aol.com> wrote: >>William Pechter wrote: >>> In article <ngqg0v11dmi@news6.newsguy.com>, >>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: >>>>On 2016-05-09, Scott Lurndal <scott@slp53.sl.home> wrote: >>>> >>>>> jmfbahciv <See.above@aol.com> writes: >>>>> >>>>>> Scott Lurndal wrote: >>>>>> >>>>>>>> Would having a buffer ring be too complicated? >>>>>>> >>>>>>> Would have been unnecessary, the double buffer algorithm used 100% of >>>>>>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>>>>>> improved performance. >>>>>>> >>>>>>> This was used in the code that installed the operating system >>(COLDSTART) >>>>>>> onto the boot media. >>>>>> >>>>>> Ah, you were the only one on the system; that makes a differnce. I was >>>>>> trying to think of a way to not have to stop the magtape because getting >>>>>> it started again would take finagling (tapes move when idle). >>>>> >>>>> Tapes on the dozen models of tape drives I used never moved when idle. >>>> >>>>If they did, it was time to call in the CE. >>> >>> Only time tapes move when they're idle is when there's some tach >>> or vacuum switch (or leak) issue making it move. Tape should be still >>> when not reading/writing or rewinding. If not call the tech to bring >>> the adjustment gear. >> >>Oh, there isn't any reading or writing going on. It just creeps a little >>bit. But everyone else is saying they never saw it. I wonder if >>it's because they weren't in a development lab. >> >>/BAH > > I saw it. Good. I don't have to explain more. > > But if the tape had any net movement we would call in field service > and have the countermoves calibrated. If the tape drive was a Real Tape[1], > and it was setup correctly it just vibrated a little bit. Right. But field service knew how to calibrate because of the work done in our lab. I suppose that the creep we saw was part of the field service work for the final product. TW would have worked with FS and the hardware engineers to solve the problem. > > [1] Which would exclude most of the DEC products. Except the good drives we put on the systems. ;-) /BAH
[toc] | [prev] | [next] | [standalone]
| From | "Simo" <dhy287@gmail.com> |
|---|---|
| Date | 2016-05-10 04:56 +1000 |
| Message-ID | <dpc4qfFiisiU1@mid.individual.net> |
| In reply to | #163470 |
"Scott Lurndal" <scott@slp53.sl.home> wrote in message news:4O1Yy.15985$6I7.4514@fx16.iad... > jmfbahciv <See.above@aol.com> writes: >>Scott Lurndal wrote: > >>>>Would having a buffer ring be too complicated? >>> >>> Would have been unnecessary, the double buffer algorithm used 100% of >>> the device (disk /tape) bandwidth as it was. Adding more wouldn't have >>> improved performance. >>> >>> This was used in the code that installed the operating system >>> (COLDSTART) >>> onto the boot media. >> >>Ah, you were the only one on the system; that makes a differnce. I was >>trying to think of a way to not have to stop the magtape because getting >>it started again would take finagling (tapes move when idle). > > Tapes on the dozen models of tape drives I used never moved when idle. Me neither.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | alt.folklore.computers
csiph-web