Here is my second round of my non scientific benchmarking and tests, I
hope this is useful.
I been having fun benchmarking these machines but I am starting to get
sick of it as well :) but I find it important to know that things are
going to work right when they are launched to do their real wor
On Sun, Oct 23, 2005 at 05:24:02PM +1000, Michael VInce wrote:
M> Here is my second round of my non scientific benchmarking and tests, I
M> hope this is useful.
M> I been having fun benchmarking these machines but I am starting to get
M> sick of it as well :) but I find it important to know that
i come across this unusual problem.
i changed the ip_tos field of the struct ip and
computed
the checksum by using in_cksum().
when the packet uses only one mbuf the computed
checksum is ok but when the packet uses more than one
mbuf then the computed checksum is wrong.
eg. pinging with payloa
On 2005-10-23 01:30, kamal kc <[EMAIL PROTECTED]> wrote:
> i come across this unusual problem.
>
> i changed the ip_tos field of the struct ip and computed the checksum
> by using in_cksum().
>
> when the packet uses only one mbuf the computed checksum is ok but
> when the packet uses more than one
On Sat, Oct 22, 2005 at 10:01:46PM +0100, Volker wrote:
[]
> Is anybody else here with deep TCP + IPSec knowledge able to get a look
> into this? Any known issues? Is there anything I might also check out?
> Is there a 64k limit with IPSec? :(
IPSec works, even for huge datas sessions: I'm usi
> > i changed the ip_tos field of the struct ip and
> computed the checksum
> > by using in_cksum().
> >
> > when the packet uses only one mbuf the computed
> checksum is ok but
> > when the packet uses more than one mbuf then the
> computed checksum is
> > wrong.
>
> Note that the IP header conta
On 2005-10-23 04:13, kamal kc <[EMAIL PROTECTED]> wrote:
> /* the argument m is the (struct mbuf *) that
> * contains the packet data
> */
>
> void copy_the_memorybuffer(struct mbuf **m)
> {
>struct mbuf *mbuf_pointer=*m;
>struct mbuf **next_packet;
>
>next_packet=&mbuf_pointer;
>
>
Yvan,
as far as I'm not totally wrong on the MTU issue, I've already checked that.
On the other side, if it's an MTU issue, wouldn't the stream break at
the first oversized packet? I mean the scp session is sending around 56k
of data through the stream and then the session stalls. My gnetcat test
On Sun, Oct 23, 2005 at 08:45:06AM +1300, Andrew Thompson wrote:
> On Sat, Oct 22, 2005 at 01:37:35PM +, Wojciech A. Koszek wrote:
> > On Fri, Oct 21, 2005 at 09:23:27AM +1300, Andrew Thompson wrote:
> > > On Thu, Oct 20, 2005 at 08:20:34PM +, Wojciech A. Koszek wrote:
> > > > Hello,
> > >
- Original Message -
From: "Marcin Jessa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, October 21, 2005 8:55 PM
Subject: Re: PPPoE and Radius on 6.0RC1
Thanks a lot.
I recompiled my kernel with the netgraph
I just have to point out that below I made a statement that proved I
should of gone to bed earlier instead of doing benchmarks :). The 901
http States and ssh state have nothing to do with each other as there on
different pf rules.
Mike
Michael VInce wrote:
I did watch the gateway (B) pf sta
> > void copy_the_memorybuffer(struct mbuf **m)
> > {
> >struct mbuf *mbuf_pointer=*m;
> >struct mbuf **next_packet;
> >
> >next_packet=&mbuf_pointer;
> >
> >struct ip *my_ip_hdr;
> >my_ip_hdr=mtod((*next_packet),struct ip *);
> >my_ip_hdr->ip_tos=64;
> >my_ip_hdr->ip_s
> > void copy_the_memorybuffer(struct mbuf **m)
> > {
> >struct mbuf *mbuf_pointer=*m;
> >struct mbuf **next_packet;
> >
> >next_packet=&mbuf_pointer;
> >
> >struct ip *my_ip_hdr;
> >my_ip_hdr=mtod((*next_packet),struct ip *);
> >my_ip_hdr->ip_tos=64;
> >my_ip_hdr->ip_s
13 matches
Mail list logo
