larry@focsys.UUCP (Larry Williamson) (12/13/88)
A bit of a followup and a request for more info. Most of the suggestions that I've received so far are good ideas, but they have not helped. I must be doing something else wrong. In article <317@focsys.UUCP> I wrote: | | Streaming tape I/O with 386/ix seems to be rather slow. The drive | is not streaming very well. It spends most of it's time stopping | and starting. I received mail from a number of people and there have been a number of articles posted answering my query. Without exception, everyone has suggested essentially the same thing, namely increase the size of the buffer that is being written to the tape. Recommendations on how best to do this differs from individual to individual. I've tried most of the suggestions. I used the 'stream' utility that came with our Bell Tech system. I used the "undocumented" cpio option '-Cn' (where n is the buffer size to write in bytes). I've used pdtar, I've piped through dd. The only thing that I've not tried yet was ... In article <8513@alice.UUCP> debra@alice.UUCP (Paul De Bra) writes: | A solution which also works for other applications is to use "cat": | find . -print | cpio -ovc | cat | cat > /dev/rmt0 I've run the system in single user mode, I've run it with 'nice -n' to give me greater priority, still no better. A 500k write takes about an hour! This same hardware works fine on our Microport SV/AT system. I was never able to use it on the Bell Tech system because the interface board was not BT's special version. Any other suggestions?? Larry -- Larry Williamson -- Focus Systems -- Waterloo, Ontario watmath!focsys!larry (519) 746-4918
roe@unibase.UUCP (Roe Peterson) (12/22/88)
From article <321@focsys.UUCP>, by larry@focsys.UUCP (Larry Williamson): > | > | Streaming tape I/O with 386/ix seems to be rather slow. The drive > | is not streaming very well. It spends most of it's time stopping > | and starting. > ... description of many good attempts with dd, etc, deleted. > A 500k write takes about an hour! Here's the problem: it sounds like your operating system is either implementing tape I/O in a blocked fashion (ie: 1K blocks, no chance to change it), or it implements both, and your /dev/rmt0 should actually be called /dev/mt0. If find..|dd with a large block size does not change the duration of a write to the tape (listen to it - with large blocks, the forward motion is audibly much longer), the device driver is chopping data into small blocks for you (this is a nono). Raw device drivers (at least, for tape) are not supposed to do this. Some systems provide both blocked and character (true rawmode) tape devices- check your manual (try mt(4) or mt(7)). Incidentally, on systems with proper device drivers (ie, most I've seen), the best way to approach streaming speed is with a utility that uses shared memory between the writer and the tape device to collect input into larger blocks. The advantage here is that the writer will not block waiting for the output to occur. If there is enough interest, I'll post a small buffering utility to comp.sources.misc. Roe Peterson. -- Roe Peterson uunet!attcan!utgpu!tmsoft!mcl!unibase!roe
larry@focsys.UUCP (Larry Williamson) (12/24/88)
From article <321@focsys.UUCP>, by larry@focsys.UUCP (.. me ..): > > Streaming tape I/O with 386/ix seems to be rather slow. The drive > is not streaming very well. It spends most of it's time stopping > and starting. I posted a followup to this discussion, but maybe it did not get out, so ... The problem that I was having turned out to be hardware related. I had an interrupt conflict. It turns out that the tape interface board had it's interrupt level set to other than the level unix expects. The tape now works like a charm. Very fast. It streams for a very long time. Thanks to all who offered suggestions. Regards, Larry. -- Larry Williamson -- Focus Systems -- Waterloo, Ontario watmath!focsys!larry (519) 746-4918