Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 02:54, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
thankyou.. I haven't looked a the PR yet but does it happen in 5.x and 4.x? On Sat, 28 Feb 2004, Daan Vreeken [PA4DAN] wrote: On Saturday 28 February 2004 02:54, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 16:32, you wrote: thankyou.. I haven't looked a the PR yet but does it happen in 5.x and 4.x? Yes, as far as I know both problems are in 4.x and 5.x . On Sat, 28 Feb 2004, Daan Vreeken [PA4DAN] wrote: On Saturday 28 February 2004 02:54, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Fri, 27 Feb 2004, Julian Elischer wrote: JE I plan to commit the MFC at http://www.josef-k.net/freebsd/ JE (the latest one) in the next couple of days. If you really care about JE USB in 4.10 you might do well to test this on your equipment, JE ESPECIALLY if you have unusual devices. Let me know of both successes JE and failures please.. If I hear nothing I won't know if it's because JE no-one tested it or it was just without problems.. JE JE Please also check these same devices without the patch BEFORE you let me JE know of any failures so that we can tell if they are truely caused by JE the patch.. Well, my main headache (SONY Clie SJ20) is now in a bit different state; before (at 4.9p1) it failed to attach with ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 now it is correctly identified (after HotSync activation) as ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 Controller /dev/usb0: addr 1: low speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, self powered, config 1, Palm Handheld(0x0066), Palm, Inc.(0x054c), rev 1.00 However, I still can't figure out how to sync, as dlpsh can't attach to /dev/ucom before activatyng Sync, and never goes to the shell prompt when statring in the middle of sync process. Googling does not help much, unfortunately. Two other USB devices I have are USB Generic storage (CF reader and MP3 player), and they seem to keep work smoothly. I had I/O errors and hangups with cheap MemoryStick reader before, but do not have it by hand to quick check. Hope to check tomorrow. Thanks for your work! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Sun, 29 Feb 2004, Dmitry Morozovsky wrote: On Fri, 27 Feb 2004, Julian Elischer wrote: JE I plan to commit the MFC at http://www.josef-k.net/freebsd/ JE (the latest one) in the next couple of days. If you really care about JE USB in 4.10 you might do well to test this on your equipment, JE ESPECIALLY if you have unusual devices. Let me know of both successes JE and failures please.. If I hear nothing I won't know if it's because JE no-one tested it or it was just without problems.. JE JE Please also check these same devices without the patch BEFORE you let me JE know of any failures so that we can tell if they are truely caused by JE the patch.. Well, my main headache (SONY Clie SJ20) is now in a bit different state; before (at 4.9p1) it failed to attach with ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 now it is correctly identified (after HotSync activation) as ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 Controller /dev/usb0: addr 1: low speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, self powered, config 1, Palm Handheld(0x0066), Palm, Inc.(0x054c), rev 1.00 However, I still can't figure out how to sync, as dlpsh can't attach to /dev/ucom before activatyng Sync, and never goes to the shell prompt when shouldn't it be /dev/ucom0? (assuming it exists) statring in the middle of sync process. Googling does not help much, unfortunately. Two other USB devices I have are USB Generic storage (CF reader and MP3 player), and they seem to keep work smoothly. I had I/O errors and hangups with cheap MemoryStick reader before, but do not have it by hand to quick check. Hope to check tomorrow. I'll go ahead with the MFC but I'll try handle these reports afterwards... Thanks for your work! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
em0, polling performance, P4 2.8ghz FSB 800mhz
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000
ethernet connected to a Cisco, both sides are locked to 1000/FD.
The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After
only a few minutes of run time under an attack ~90,000 pps. The attack
has been limited at the router to JUST incoming TCP port 80 inbound
traffic. I don't know why the machine is having such a hard time under
the load. The cpu shows it is 90% idle even under the worst of the
attack. What am I doing wrong?
Thanks,
DJ
#sysctl -a |grep hz
kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024,
stathz = 1
28 }
#sysctl -a |grep polling
kern.polling.burst: 544
kern.polling.each_burst: 30
kern.polling.burst_max: 550
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 30
kern.polling.short_ticks: 44151
kern.polling.lost_polls: 84925
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 39272
kern.polling.stalled: 5
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004
Timecounter i8254 frequency 1193182 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf29 Stepping = 9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
real memory = 2147418112 (2097088K bytes)
avail memory = 2085978112 (2037088K bytes)
Preloaded elf kernel kernel at 0xc04fa000.
Warning: Pentium 4 CPU: PSE disabled
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 12 entries at 0xc00fdea0
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: PCI to PCI bridge (vendor=8086 device=2579) at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib2: PCI to PCI bridge (vendor=8086 device=257b) at device 3.0 on pci0
pci2: PCI bus on pcib2
em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port
0xb000-0xb01f
mem 0xf300-0xf301 irq 12 at device 1.0 on pci2
em0: Speed:N/A Duplex:N/A
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xcc00-0xcc1f
irq 11 at
device 29.0 on pci0
usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xc000-0xc01f
irq 3 at d
evice 29.1 on pci0
usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xc400-0xc41f
irq 12 at
device 29.2 on pci0
usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xc800-0xc81f
irq 11 at
device 29.3 on pci0
usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
pci0: USB controller at 29.7 irq 7
pcib3: Intel 82801BA/BAM (ICH2) Hub to PCI bridge at device 30.0 on pci0
pci3: PCI bus on pcib3
ahd0: Adaptec 29320LP Ultra320 SCSI adapter port
0x9400-0x94ff,0x9000-0x90ff m
em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3
aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
pci3: unknown card (vendor=0x105a, dev=0x3373) at 3.0 irq 10
pci3: ATI Mach64-GR graphics accelerator at 7.0 irq 11
pci3: unknown card (vendor=0x8086, dev=0x1051) at 8.0 irq 5
isab0: PCI to ISA bridge (vendor=8086 device=24d0) at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 ATA100 controller port
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0
x7 irq 0 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: unknown card (vendor=0x8086, dev=0x24d3) at 31.3 irq 9
orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0
pmtimer0 on isa0
fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: configured irq 3 not in bitmap of probed irqs 0
ppc0: parallel port not found.
DUMMYNET initialized (011031)
IP packet filtering
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is 90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
It was kindly pointed out that I didn't including the symptoms of the
problem:
Without polling on, I get 70+% interrupt load, and I get live lock.
With polling on, I start getting huge amounts of input errors, packet
loss, and general unresponsiveness to the network. The web server on it
doesn't respond though it occassionally will open the connection, just
not respond. accept_filter on/off makes no difference. I have read other
posts that say em systems can more 200kpps without serious incident.
Thanks in advance,
DJ
Deepak Jain wrote:
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000
ethernet connected to a Cisco, both sides are locked to 1000/FD.
The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After
only a few minutes of run time under an attack ~90,000 pps. The attack
has been limited at the router to JUST incoming TCP port 80 inbound
traffic. I don't know why the machine is having such a hard time under
the load. The cpu shows it is 90% idle even under the worst of the
attack. What am I doing wrong?
Thanks,
DJ
#sysctl -a |grep hz
kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024,
stathz = 1
28 }
#sysctl -a |grep polling
kern.polling.burst: 544
kern.polling.each_burst: 30
kern.polling.burst_max: 550
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 0
kern.polling.user_frac: 50
kern.polling.reg_frac: 30
kern.polling.short_ticks: 44151
kern.polling.lost_polls: 84925
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 39272
kern.polling.stalled: 5
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004
Timecounter i8254 frequency 1193182 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf29 Stepping = 9
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Hyperthreading: 2 logical CPUs
real memory = 2147418112 (2097088K bytes)
avail memory = 2085978112 (2037088K bytes)
Preloaded elf kernel kernel at 0xc04fa000.
Warning: Pentium 4 CPU: PSE disabled
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 12 entries at 0xc00fdea0
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: PCI to PCI bridge (vendor=8086 device=2579) at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib2: PCI to PCI bridge (vendor=8086 device=257b) at device 3.0 on pci0
pci2: PCI bus on pcib2
em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port
0xb000-0xb01f
mem 0xf300-0xf301 irq 12 at device 1.0 on pci2
em0: Speed:N/A Duplex:N/A
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xcc00-0xcc1f
irq 11 at
device 29.0 on pci0
usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xc000-0xc01f
irq 3 at d
evice 29.1 on pci0
usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xc400-0xc41f
irq 12 at
device 29.2 on pci0
usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xc800-0xc81f
irq 11 at
device 29.3 on pci0
usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3
usb3: USB revision 1.0
uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
pci0: USB controller at 29.7 irq 7
pcib3: Intel 82801BA/BAM (ICH2) Hub to PCI bridge at device 30.0 on pci0
pci3: PCI bus on pcib3
ahd0: Adaptec 29320LP Ultra320 SCSI adapter port
0x9400-0x94ff,0x9000-0x90ff m
em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3
aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs
pci3: unknown card (vendor=0x105a, dev=0x3373) at 3.0 irq 10
pci3: ATI Mach64-GR graphics accelerator at 7.0 irq 11
pci3: unknown card (vendor=0x8086, dev=0x1051) at 8.0 irq 5
isab0: PCI to ISA bridge (vendor=8086 device=24d0) at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 ATA100 controller port
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0
x7 irq 0 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: unknown card (vendor=0x8086, dev=0x24d3) at 31.3 irq 9
orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0
pmtimer0 on
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is 90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). I'd like to know more about the CPU time idea. I have net.inet.udp.blackhole=2 and net.inet.tcp.blackhole=2 because I saw a lot of dstunreachable packets out. The system can hyperthread, but I thought the singlethreading of polling might have been an issue, so I recompiled the kernel without SMP. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
And this was picked up in the messages log: /kernel: stray irq 7 last message repeated 2 times /kernel: too many stray irq 7's; not logging any more DJ Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is 90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
It was kindly pointed out that I didn't including the symptoms of the problem: Without polling on, I get 70+% interrupt load, and I get live lock. With polling on, I start getting huge amounts of input errors, packet loss, and general unresponsiveness to the network. The web server on it doesn't respond though it occassionally will open the connection, just not respond. accept_filter on/off makes no difference. I have read other posts that say em systems can more 200kpps without serious incident. Thanks in advance, DJ You may need to increase the MAX_RXD inside your em driver to e.g. 512. With similar system, em can handle ~800Kpps of bridging. Your earlier email showed a very large number of RST messages, which makes me suspect the blackhole actually wasn't enabled. Not exactly sure what you're trying to do here. It sounds like you are trying to generate a SYN flood on port 80, and your listen queue is backing up. You've increased kern.ipc.somaxconn? Does your application specify a fixed listen queue depth? Could it be increased? Are you using apache as the server? Could you use a kqueue-enabled one like thttpd? Have you checked net.inet.ip.intr_queue_drops? If its showing 0, check net.inet.ip.intr_queue_maxlen, perhaps increase it. Have you sufficient mbufs and clusters? netstat -m. If you want to spend more time in kernel, perhaps change kern.polling.user_frac to 10? I might have HZ @ 2500 as well. You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. now... this will switch the DoS condition to elsewhere in the kernel, and it might not win you anything. net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 might be called for if you try that approach. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: It was kindly pointed out that I didn't including the symptoms of the problem: Without polling on, I get 70+% interrupt load, and I get live lock. With polling on, I start getting huge amounts of input errors, packet loss, and general unresponsiveness to the network. The web server on it doesn't respond though it occassionally will open the connection, just not respond. accept_filter on/off makes no difference. I have read other posts that say em systems can more 200kpps without serious incident. Thanks in advance, DJ You may need to increase the MAX_RXD inside your em driver to e.g. 512. I didn't know if my card had a buffer bigger than the default 256. I can increase it, but I didn't know how to determine how big a MAX_RXD my card would support. When the system was under load, it was generating 2xHZ clock ticks (2000 when HZ was 1000) is that normal? With similar system, em can handle ~800Kpps of bridging. What settings did you use? Your earlier email showed a very large number of RST messages, which makes me suspect the blackhole actually wasn't enabled. Not exactly sure what you're trying to do here. It sounds like you are trying to generate a SYN flood on port 80, and your listen queue is backing up. You've increased kern.ipc.somaxconn? Does your application specify a fixed listen queue depth? Could it be increased? Are you using apache as the server? Could you use a kqueue-enabled one like thttpd? Using apache, might go to squid or thttpd. Didn't think it should make a big deal. Increased somaxconn. Basically the system is getting hammered (after all filtering at the router) with valid get requests on port 80. Have you checked net.inet.ip.intr_queue_drops? If its showing 0, check net.inet.ip.intr_queue_maxlen, perhaps increase it. net.inet.ip.intr_queue_maxlen: 500 net.inet.ip.intr_queue_drops: 0 p1003_1b.sigqueue_max: 0 No intr drops. Have you sufficient mbufs and clusters? netstat -m. 1026/5504/262144 mbufs in use (current/peak/max): 1026 mbufs allocated to data 1024/5460/65536 mbuf clusters in use (current/peak/max) 12296 Kbytes allocated to network (6% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines mbufs look fine. If you want to spend more time in kernel, perhaps change kern.polling.user_frac to 10? I'll do that. I might have HZ @ 2500 as well. You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 This is a great idea. We were trapping those who crossed our connection thresholds and blackholing them upstream (automatically, with a script). this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. now... this will switch the DoS condition to elsewhere in the kernel, and it might not win you anything. net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 might be called for if you try that approach. I see where that should get us. We'll see. Thanks! DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
... You may need to increase the MAX_RXD inside your em driver to e.g. 512. I didn't know if my card had a buffer bigger than the default 256. I can increase it, but I didn't know how to determine how big a MAX_RXD my card would support. When the system was under load, it was generating 2xHZ clock ticks (2000 when HZ was 1000) is that normal? max_rxd is not a function of the card. its the system ram you devote to dma buffers. Too big will cause problems since it will flush through the cache etc. you should get (vmstat -i) a clk rate that exactly matches hz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
On Sat, 28 Feb 2004, Don Bowman wrote: You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( I know that if I rate shape the setup traffic, it helps. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
