On Fri, 2 Feb 2001, Yu-Shun Wang wrote:
> What you pointed out below is true. But I am more
> interested in the relative performance since the number
> I measured were under exactly the same setup and traffic
> condition.
I believe it is a common pitfall to assume that sa
> What you pointed out below is true. But I am more
> interested in the relative performance since the number
> I measured were under exactly the same setup and traffic
> condition. I am just curious why IPComp was _relatively_
> (and signigicantly) slower than most
On Fri, 2 Feb 2001, Yu-Shun Wang wrote:
> Hi,
>
> What you pointed out below is true. But I am more
> interested in the relative performance since the number
> I measured were under exactly the same setup and traffic
> condition. I am just curious why IPComp was _relative
Hi,
What you pointed out below is true. But I am more
interested in the relative performance since the number
I measured were under exactly the same setup and traffic
condition. I am just curious why IPComp was _relatively_
(and signigicantly) slower than m
On Thu, 1 Feb 2001, Yu-Shun Wang wrote:
> Another (sort of) related question: I've got the bandwidth
> measurements for different algorthms using netperf. I was
> really surprised that IPComp did so bad. Any ideas?
AFAIK, netperf TCP_STREAM test (and may be others) is extremely
> Another (sort of) related question: I've got the bandwidth
> measurements for different algorthms using netperf. I was
> really surprised that IPComp did so bad. Any ideas?
thanks for measurements, it's good to see.
i guess couple of reasons here.
-
Hi,
Another (sort of) related question: I've got the bandwidth
measurements for different algorthms using netperf. I was
really surprised that IPComp did so bad. Any ideas?
TCP UDP(Mbps) Ping(ms)Key(bits)
-
Hi,
It turned out that the problem is in netinet/in_proto.c.
(It might have been fixed in -stable long ago, but not
in 4.2 release. :-)
yushun.
--- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001
+++ /usr/src/sys/netinet/in_proto.c.ORIGThu F
> No, but the problem is that there was no increase (actually, no
> record at all) under ipsec: IPComp. The number on the sending
> side seemed right. The increase matched the ones I saw from
> tcpdump. It looked like the IPComp packets either weren't
> logged or wer
> > I tried to measure bandwidth with IPComp enabled, but kept
> > getting the error message "no response" from netperf
> > (/usr/ports/benchmark/netperf).
> >
> > For all I could tell from tcpdump, netperf established ctrl
> > channel, and about 5 to 8 packets were sent with I
>Hi,
> I tried to measure bandwidth with IPComp enabled, but kept
> getting the error message "no response" from netperf
> (/usr/ports/benchmark/netperf).
>
> For all I could tell from tcpdump, netperf established ctrl
> channel, and about 5 to 8 packets were sent wi
Hi,
I tried to measure bandwidth with IPComp enabled, but kept
getting the error message "no response" from netperf
(/usr/ports/benchmark/netperf).
For all I could tell from tcpdump, netperf established ctrl
channel, and about 5 to 8 packets were sent with
12 matches
Mail list logo
