Re: dummynet pipe show problem
On Wed, Nov 21, 2001 at 03:02:49PM -0800, rick norman wrote:
Hi,
I'm still running into lots of problems with this on 4.3. Is it neccessary
to introduce a delay in the pipe ? Would a delay of zero work ?
Has this been fixed in 4.4 ?
Thinking about it, I believe it might be a problem with
the routing code, not with dummynet, and it has to do with the
fact that you delete and reassign the address to the
loopback interface.
I am almost sure that 4.4 would cure the problem, because
that problem was fixed before 4.4.
cheers
luigi
Rick
Luigi Rizzo wrote:
On Tue, Oct 30, 2001 at 10:47:33AM -0800, rick norman wrote:
Hi,
I have enclosed a short piece of code that seems to
reproduce the problem after 5 to 10 minutes.
I am running 4.3 freebsd off the release cd's.
Pretty much the generic kernel except for the
addition of dummynet and ipfw. My platform
is a dell dimension 4100 with 1ghz p3, though
I doubt that is relevant. To reproduce the problem,
compile and run the enclosed code in one window.
In another window su to root and run ping -s 1024 -f 127.0.42.1.
As you will see, the code reports the gowing byte count as one
would expect. Walk away for 5 to 10 minutes and when you come
back you should see the state I'm talking about. The flood ping stream
It _might_ be a locking problem due to the frequent
reconfigurations of the pipe -- i think there was some
fix of this kind related to ipfw commands between 4.3 and 4.4.
I will see if i can reproduce the problem locally (but i have
4.4).
You are using dummynet in a very peculiar way:
more precisely, your pipe does not introduce any delay,
and this excludes the scheduler which is part of dummynet.
Also you are using the same pipe for icmp requests
and replies, which are generated within the kernel, so
the behaviour should be quite deterministic in this
respect.
thanks for the report
luigi
Thanks,
Rick
--cut
main() {
int i;
restart:
system(ifconfig lo0 -alias 127.0.42.1);
system(ifconfig lo0 alias 127.0.42.1 netmask 255.255.255.0);
system(ipfw -f flush);
system(ipfw pipe 1 delete);
system(ipfw add pipe 1 ip from 127.0.42.0/24 to any in);
for(i=0;i5;i++) {
system(ipfw pipe 1 config queue 2048Bytes);
sleep(1);
system(ipfw pipe 1 show);
}
goto restart;
}
cut--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: dummynet pipe show problem
Hi,
I'm still running into lots of problems with this on 4.3. Is it neccessary
to introduce a delay in the pipe ? Would a delay of zero work ?
Has this been fixed in 4.4 ?
Rick
Luigi Rizzo wrote:
On Tue, Oct 30, 2001 at 10:47:33AM -0800, rick norman wrote:
Hi,
I have enclosed a short piece of code that seems to
reproduce the problem after 5 to 10 minutes.
I am running 4.3 freebsd off the release cd's.
Pretty much the generic kernel except for the
addition of dummynet and ipfw. My platform
is a dell dimension 4100 with 1ghz p3, though
I doubt that is relevant. To reproduce the problem,
compile and run the enclosed code in one window.
In another window su to root and run ping -s 1024 -f 127.0.42.1.
As you will see, the code reports the gowing byte count as one
would expect. Walk away for 5 to 10 minutes and when you come
back you should see the state I'm talking about. The flood ping stream
It _might_ be a locking problem due to the frequent
reconfigurations of the pipe -- i think there was some
fix of this kind related to ipfw commands between 4.3 and 4.4.
I will see if i can reproduce the problem locally (but i have
4.4).
You are using dummynet in a very peculiar way:
more precisely, your pipe does not introduce any delay,
and this excludes the scheduler which is part of dummynet.
Also you are using the same pipe for icmp requests
and replies, which are generated within the kernel, so
the behaviour should be quite deterministic in this
respect.
thanks for the report
luigi
Thanks,
Rick
--cut
main() {
int i;
restart:
system(ifconfig lo0 -alias 127.0.42.1);
system(ifconfig lo0 alias 127.0.42.1 netmask 255.255.255.0);
system(ipfw -f flush);
system(ipfw pipe 1 delete);
system(ipfw add pipe 1 ip from 127.0.42.0/24 to any in);
for(i=0;i5;i++) {
system(ipfw pipe 1 config queue 2048Bytes);
sleep(1);
system(ipfw pipe 1 show);
}
goto restart;
}
cut--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: dummynet pipe show problem
On Tue, Oct 30, 2001 at 10:47:33AM -0800, rick norman wrote:
Hi,
I have enclosed a short piece of code that seems to
reproduce the problem after 5 to 10 minutes.
I am running 4.3 freebsd off the release cd's.
Pretty much the generic kernel except for the
addition of dummynet and ipfw. My platform
is a dell dimension 4100 with 1ghz p3, though
I doubt that is relevant. To reproduce the problem,
compile and run the enclosed code in one window.
In another window su to root and run ping -s 1024 -f 127.0.42.1.
As you will see, the code reports the gowing byte count as one
would expect. Walk away for 5 to 10 minutes and when you come
back you should see the state I'm talking about. The flood ping stream
It _might_ be a locking problem due to the frequent
reconfigurations of the pipe -- i think there was some
fix of this kind related to ipfw commands between 4.3 and 4.4.
I will see if i can reproduce the problem locally (but i have
4.4).
You are using dummynet in a very peculiar way:
more precisely, your pipe does not introduce any delay,
and this excludes the scheduler which is part of dummynet.
Also you are using the same pipe for icmp requests
and replies, which are generated within the kernel, so
the behaviour should be quite deterministic in this
respect.
thanks for the report
luigi
Thanks,
Rick
--cut
main() {
int i;
restart:
system(ifconfig lo0 -alias 127.0.42.1);
system(ifconfig lo0 alias 127.0.42.1 netmask 255.255.255.0);
system(ipfw -f flush);
system(ipfw pipe 1 delete);
system(ipfw add pipe 1 ip from 127.0.42.0/24 to any in);
for(i=0;i5;i++) {
system(ipfw pipe 1 config queue 2048Bytes);
sleep(1);
system(ipfw pipe 1 show);
}
goto restart;
}
cut--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
