[Xorp-users] measuring update processing time

[Mark Handley]

------=_Part_1181_6508192.1126304427944
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 9/9/05, Ratul Mahajan <ratul@cs.washington.edu> wrote:

> does anyone know what the best way is to measure (BGP) update processing
> time, starting from when the message arrives at the box? given that the
> implementation is single-threaded, measuring it from within the xorp
> code will ignore time for which the message was sitting in the socket
> buffers, right?


You're right that messages can spend some time in either the outgoing socke=
t=20
buffer on the sending machine, or the inbound socket buffer on the receivin=
g=20
machine. In general, the time spent in the socket buffer on the receiving=
=20
machine should be very short if the machine is underloaded, but it's pretty=
=20
hard to measure exactly what it is.

Being single-threaded or multi-threaded doesn't change things (unless you'v=
e=20
got multiple CPUs) in either case. If the machine is underloaded, the=20
interval will be equally short.=20

In the overload case, you want to push back to the socket buffer in either=
=20
case. This is the only way you can rate control incoming data, and if you=
=20
can't handle the update rate, you don't want to build the queue up=20
internally, because that's a guaranteed way to run out of memory. Better to=
=20
push back to the router upstream, and let it generate the messages at a rat=
e=20
you can handle. Thus even a multi-threaded solution would best block back t=
o=20
the socket buffer under overload conditions.

This doesn't answer your question, but perhaps means that under some=20
circumstances the question isn't the right question?

- Mark

------=_Part_1181_6508192.1126304427944
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class=3D"gmail_quote">On 9/9/05, <b class=3D"gmail_sende=
rname">Ratul Mahajan</b> &lt;<a href=3D"mailto:ratul@cs.washington.edu">rat=
ul@cs.washington.edu</a>&gt; wrote:</span><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">does anyone know =
what the best way is to measure (BGP) update processing<br>time, starting f=
rom when the message arrives at the box? given that the
<br>implementation is single-threaded, measuring it from within the xorp<br=
>code will ignore time for which the message was sitting in the socket<br>b=
uffers, right?</blockquote><div><br>
You're right that messages can spend some time in either the outgoing
socket buffer on the sending machine, or the inbound socket buffer on
the receiving machine.&nbsp; In general, the time spent in the socket
buffer on the receiving machine should be very short if the machine is
underloaded, but it's pretty hard to measure exactly what it is.<br>
<br>
Being single-threaded or multi-threaded doesn't change things (unless
you've got multiple CPUs) in either case.&nbsp;&nbsp;&nbsp; If the
machine is underloaded, the interval will be equally short. <br>
<br>
In the overload case, you want to push back to the socket buffer in
either case.&nbsp; This is the only way you can rate control incoming
data, and if you can't handle the update rate, you don't want to build
the queue up internally, because that's a guaranteed way to run out of
memory.&nbsp; Better to push back to the router upstream, and let it
generate the messages at a rate you can handle.&nbsp; Thus even a
multi-threaded solution would best block back to the socket buffer
under overload conditions.<br>
<br>
This doesn't answer your question, but perhaps means that under some circum=
stances the question isn't the right question?<br>
<br>
- Mark<br>
</div></div>

------=_Part_1181_6508192.1126304427944--