This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C20B31.F306D710
Content-Type: text/plain
It was written with the same methods as the other so no differences there.
I did find a lot of these in the bptm log:
12:45:42 [10353] <2> fill_buffer: [10345] socket is closed, waited for empty
buffer 3076 times, delayed 7019 times, read 838893568 bytes
Which, according to this http://seer.support.veritas.com/docs/244652.htm
might indicate insufficient buffers. I've doubled the NUMBER_DATA_BUFFERS
in response from 32 to 64.
I don't know if the "dd" would be a good check as NB uses variable block
sizes and "dd" is going to use a fixed block size.
-M
-----Original Message-----
From: Darren Dunham [mailto:ddunham AT taos DOT com]
Sent: Monday, June 03, 2002 1:00 PM
To: Mark.Donaldson AT experianems DOT com
Subject: Re: [Veritas-bu] DLT Read vs. Write speeds
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C20B2D.751E5070
> Content-Type: text/plain
>
> I'm reading a multiplexed backup with the job below. The write jobs you
see
> are non-multiplexed. Still, that shouldn't make much a difference for
> KB/sec like below - NB has to read every block of the MPX tape and cull
out
> the needed data from there - input speed should be at close to drive speed
> of 5-7M/sec or so. The MPX source tape should just mean that the actual
> data rate sent to the client would be less that the 409 KB/sec below.
Yes. I absolutely agree. I wasn't talking about MPX. I just wanted to
make certain that you weren't reading a tape from some other source
written with a strange block size or something like that.
If 'dd' gives you the same rate, I'd suspect something is going on with
the drive or the scsi bus.
If 'dd' is significantly faster, I'd start poking around the logs and
see if anything pops up.
--
Darren Dunham ddunham AT taos DOT com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------_=_NextPart_001_01C20B31.F306D710
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Veritas-bu] DLT Read vs. Write speeds</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>It was written with the same methods as the other so =
no differences there. I did find a lot of these in the bptm =
log:</FONT>
</P>
<P><FONT SIZE=3D2>12:45:42 [10353] <2> fill_buffer: [10345] =
socket is closed, waited for empty buffer 3076 times, delayed 7019 =
times, read 838893568 bytes</FONT></P>
<P><FONT SIZE=3D2>Which, according to this <A =
HREF=3D"http://seer.support.veritas.com/docs/244652.htm"; =
TARGET=3D"_blank">http://seer.support.veritas.com/docs/244652.htm</A> =
might indicate insufficient buffers. I've doubled the =
NUMBER_DATA_BUFFERS in response from 32 to 64.</FONT></P>
<P><FONT SIZE=3D2>I don't know if the "dd" would be a good =
check as NB uses variable block sizes and "dd" is going to =
use a fixed block size.</FONT></P>
<P><FONT SIZE=3D2>-M</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Darren Dunham [<A =
HREF=3D"mailto:ddunham AT taos DOT com">mailto:ddunham AT taos DOT
com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, June 03, 2002 1:00 PM</FONT>
<BR><FONT SIZE=3D2>To: Mark.Donaldson AT experianems DOT com</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [Veritas-bu] DLT Read vs. Write =
speeds</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> This message is in MIME format. Since your mail =
reader does not understand</FONT>
<BR><FONT SIZE=3D2>> this format, some or all of this message may =
not be legible.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
------_=3D_NextPart_001_01C20B2D.751E5070</FONT>
<BR><FONT SIZE=3D2>> Content-Type: text/plain</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I'm reading a multiplexed backup with the job =
below. The write jobs you see</FONT>
<BR><FONT SIZE=3D2>> are non-multiplexed. Still, that =
shouldn't make much a difference for</FONT>
<BR><FONT SIZE=3D2>> KB/sec like below - NB has to read every block =
of the MPX tape and cull out</FONT>
<BR><FONT SIZE=3D2>> the needed data from there - input speed should =
be at close to drive speed</FONT>
<BR><FONT SIZE=3D2>> of 5-7M/sec or so. The MPX source tape =
should just mean that the actual</FONT>
<BR><FONT SIZE=3D2>> data rate sent to the client would be less that =
the 409 KB/sec below.</FONT>
</P>
<P><FONT SIZE=3D2>Yes. I absolutely agree. I wasn't talking =
about MPX. I just wanted to</FONT>
<BR><FONT SIZE=3D2>make certain that you weren't reading a tape from =
some other source</FONT>
<BR><FONT SIZE=3D2>written with a strange block size or something like =
that.</FONT>
</P>
<P><FONT SIZE=3D2>If 'dd' gives you the same rate, I'd suspect =
something is going on with</FONT>
<BR><FONT SIZE=3D2>the drive or the scsi bus.</FONT>
</P>
<P><FONT SIZE=3D2>If 'dd' is significantly faster, I'd start poking =
around the logs and</FONT>
<BR><FONT SIZE=3D2>see if anything pops up.</FONT>
</P>
<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Darren =
Dunham =
=
=
ddunham AT taos DOT com</FONT>
<BR><FONT SIZE=3D2>Unix System =
Administrator  =
; Taos - The =
SysAdmin Company</FONT>
<BR><FONT SIZE=3D2>Got some Dr =
Pepper?  =
;  =
; San Francisco, CA bay area</FONT>
<BR><FONT SIZE=3D2> =
< This line left intentionally blank to confuse you. ></FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C20B31.F306D710--
|
