Seeking performance tuning pointers/tracking down GIANT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I read man tuning and did some goggling. Yet questions remain. System: Dual processor Intel PentiumPro motherboard. FreeBSD 5.3 SMP kernel. fxp 100baseT NIC. I am managing a system that is running tor, a fairly network intensive service. See http://tor.eff.org The service processes about 7Mbps symmetric traffic sustained. top shows about 33% CPU idle. There is plenty of inactive/free RAM. While server throughput grew steadily over time, throughput appears to have hit a ceiling at between 7 and 8 Mbps. The bottleneck is not upstream from the server. I am trying to track down the bottleneck inside the server that is establishing this ceiling. I played around with various sysctl variables, but to no effect. One thing that I do notice is that the main tor process tends to spend a fair amount of time in GIANT. Does perhaps one of the readers of this list have any suggestions how to determine where the bottleneck may be found and if so how to remove it? Thanks, - --Luck Content-Type: text/plain This email was not PGP encrypted. My next email to you could be PGP encrypted, if you click on to the URL below: https://keys.cypherpunks.to/b/b.e?r=freebsd-questions%40freebsd.comn=hFP433Ce%2FD7ivfZPVmDksg%3D%3D -BEGIN PGP SIGNATURE- Version: 1537 iQIVAwUBQftodwRVjUj9NCi0AQIj1RAAwhWTaeGc/XBossmqvfyWac3LqEDqJF3r MhC660n+ixh5Bc4ajOuOY4402YSLhdzkMY9dU5rJvONW3LnXikDQiPE40QCCaxNn euwKIVMI7E+IeqCn2cx+br7ZQEkEF6JT4kJXmvi142TWNrKyuV/2GDky3I4hj068 la+8J+Xp6toOB5FemlUs7oMApZkcqnA1ixNO/nrNXoke2NaZu+sxjWTelVOv5r8T ewuOgUL+uWvJ+cyGR6heXgsgynVoeVBm+rkv7LrEGS9WJPQJI72u46pYFFlQfDFz X96qiJALHTky8ey/+e/jB2+LUoq3e3UsxKPN+dJ7JuddasvkfciOJ4/ry6se1/Jv 0YQQeNu7Z7c2qomk7SOs66AQYlCiwXJc3AfQl7wKTYSTwaXSNBkbeq6j8+gTeWQx p5JZmu4cmkK5YN4wMxpWhNAdcUryHlCCpVNj6cPjPNqnQsdXfIhpT9qlnS4OjcPd ne8ZbD3e+uEyvoQJHwo+XQ8UNkYww31U95aOlNcirVgGhe7vtKxULp2tHMebk271 Ift0KGTWAnJBIO0EFfonekzLaTiEparv32rgFHI//hMksdkfv9qRNYaMYFcOgvqg 96dWZ0czd6MeQaLzRU8642keDHXiq5znXnOcUyNhRt45C30cFrKm0mgu0fqq3SV8 QIsAS69/Sbg= =I6BX -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
DEVICE_POLLING vs. SMP kernels
I am contemplating using the DEVICE_POLLING kernel option with an fxp NIC on FreeBSD 5.3 using an SMP kernel. /usr/src/sys/kern/kern_poll.c clearly states that DEVICE_POLLING is incompatible with SNP kernels: #ifdef SMP #ifndef COMPILING_LINT #error DEVICE_POLLING is not compatible with SMP #endif #endif Yet there are various performance tuning FAQs floating around the Net stating that DEVICE_POLLING will work just fine with SMP kernels and that the user can safely delete the above section from kern_poll.c This may well be the case, but if this is true, why wouldn't that section have been removed from kern_poll.c by now? What are the corner cases, if any, that an admin should be aware of that keep this error message in the code? TIA, -- Lucky Green [EMAIL PROTECTED] PGP encrypted email preferred. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
kern.maxfiles formula?
I am running FreeBSD 5.3 on a dual CPU system with 1 GB of RAM with under a dozen of very active users and a few rather active processes. The system keeps running out of FDs, causing any number of problems, such as preventing ssh logins. sysctl kern.maxfiles shows a maximum of 12328 FDs. My kernel config file has maxusers set to 0, which means the kern.maxfiles limit must be the OS default. What is the maximum number of FDs that can be set on a system with 1 GB of RAM? What would it be for 2 GB of RAM? In other words, how many FDs can a FreeBSD 5.3 system safely support for each GB of RAM? Thanks, --Lucky This email was not PGP encrypted. The next email can be PGP encrypted, but for this to happen you need to first click on to the URL below: https://keys.cypherpunks.to/b/b.e?r=freebsd-questions%40freebsd.orgn=IAwOVV4jo0Vi3U6uOkiaEA%3D%3D ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dual NICs, can only connect to one at time
I have a box with both an external and internal NIC. The external NIC is connected to an ADSL adapter serving a block of globally routable static IP addresses while the internal NIC is connected to a hub served by a NAT/DHCP server. The idea here is that this way the box can offer different services on the outside vs. the inside. The machine should not route packets and is not configured as a router. Unfortunately, with the external NIC enabled, the internal NIC cannot be pinged from the inside. A similar setup worked perfectly fine when an USB Ethernet adapter was used as the internal NIC. Only after switching to a PCI card as the internal NIC did this problem manifest. (The new card has been tested and works fine when used by itself). I am using FreeBSD 4.6.2. From rc.conf: # External static IP via 3COM card ifconfig_xl0=inet 208.201.229.161 netmask 255.255.255.0 hostname=cheesy.dhs.org defaultrouter=208.201.229.1 # Internal IP reserved from DHCP pool via D-Link card ifconfig_rl0=inet 192.168.0.103 netmask 255.255.255.0 The above gives an ifconfig of: 2# ifconfig rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.0.103 netmask 0xff00 broadcast 192.168.0.255 inet6 fe80::205:5dff:fe34:8133%rl0 prefixlen 64 scopeid 0x1 ether 00:05:5d:34:81:33 media: Ethernet autoselect (100baseTX full-duplex) status: active xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3rxcsum,txcsum inet 208.201.229.161 netmask 0xff00 broadcast 208.201.229.255 inet6 fe80::250:4ff:fed1:8a4a%xl0 prefixlen 64 scopeid 0x2 ether 00:50:04:d1:8a:4a media: Ethernet autoselect (100baseTX full-duplex) status: active [...] Even though both interfaces are up, 208.201.229.161 cannot be accessed from the outside. Though 208.201.229.161 can be accessed from the inside. Removing xl0 from rc.conf and changing the rl0 config to ifconfig_rl0=DHCP allows the internal NIC to be pinged. Just removing xl0 while leaving rl0 in the static configuration caused both interface to not respond to pings. For completeness, here is the ifconfig when rl0 is using DHCP: rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::205:5dff:fe34:8133%rl0 prefixlen 64 scopeid 0x1 inet 192.168.1.103 netmask 0xff00 broadcast 192.168.1.255 ether 00:05:5d:34:81:33 media: Ethernet autoselect (100baseTX full-duplex) status: active What am I missing? Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: Linux emulation: acd0a is not a cooked ioctl CDROM
Lowell wrote:
Lucky Green [EMAIL PROTECTED] writes:
Do you believe that the ATAPI/CAM patches at
http://www.cuivre.fr.eu.org/~thomas/atapicam/ might make cdparanoia
compatible with an ATAPI drive on FreeBSD?
Probably.
I guess that
would mean the
patches would have to provide the cooked ioctl that cdparanoia
wants.
Not necessarily. Also not important.
Thanks everybody for their help. I made some progress. After installing
the ATAPI/CAM patches on FreeBSD 4.6.2, cdparanoia now sees my ATAPI
CDROM drive, though cdparanoia can't read from the drive because
cdparanoia erroneously believes that the drive does not support CDDA.
I have verified that I can access the drive using cdda2wav using both
/dev/acd0c (ATAPI) and 0,0,0 (SCSI). [cdda2wav does not seem to support
the /dev/* notation for SCSI CDROM drives].
Output follows. Note the error message about ioctl's at the bottom.
Any ideas what to try next?
Thanks,
--Lucky Green
--
su-2.05b# ./cdparanoia -vsQ
cdparanoia III release 9.7 (December 13, 1999)
(C) 1999 Monty [EMAIL PROTECTED] and Xiphophorus
Report bugs to [EMAIL PROTECTED]
http://www.xiph.org/paranoia/
Checking /dev/cdrom for cdrom...
Testing /dev/cdrom for cooked ioctl() interface
CDROM sensed: Sony CDU31A or compatible
TOC entry claims an overly large start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims a negative start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims a negative start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims a negative start offset: massaging.
TOC entry claims an overly large start offset: massaging.
TOC entry claims a negative start offset: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging.
TOC entries claim non-increasing offsets: massaging. Verifying
drive can read CDDA...
Unable to read any data; drive probably not CDDA capable.
006: Could not read any data from drive
Cdparanoia could not find a way to read audio from this drive.
su-2.05b# cdrecord -scanbus
Cdrecord 1.11a28 (i386-unknown-freebsd4.6.2) Copyright (C) 1995-2002
Jörg
Schilling
Using libscg version 'schily-0.6'
scsibus0:
0,0,0 0) 'YAMAHA ' 'CRW4416E' '1.0j' Removable
CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
su-2.05b#
[...]
/var/log/messages shows the following error:
From /var/log/messages:
Oct 9 14:31:43 cheesy /kernel: linux: 'ioctl' fd=3, cmd=0x5310 ('S',16)
not
implemented
Oct 9 14:31:43 cheesy /kernel: linux: 'ioctl' fd=3, cmd=0x530e ('S',14)
not
implemented
---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
RE: Linux emulation: acd0a is not a cooked ioctl CDROM
Nick wrote: Checking /dev/cdrom for cdrom... Testing /dev/cdrom for cooked ioctl() interface /dev/acd0a is not a cooked ioctl CDROM. Testing /dev/cdrom for SCSI interface /dev/cdrom is not a SCSI device That doesn't look quite right; CDROM devices are usually accessed as /dev/acd0c in FreeBSD. Perhaps double check to see where the /dev/cdroma symlink points to. I have been able to rip from /dev/cdrom linking to /dev/acd0a using cdda2wav without a problem. I just changed /dev/cdrom to link to /dev/acd0c and am getting the same error. I suspect that somehow cdparanoia/Linux binaries are expecting the cdrom device to be of a different form than what that device looks like under FreeBSD. Which gets us back to the question of what a cooked ioctl is and how one could perhaps create a device entry for a CDROM under FreeBSD that would meet the cooked ioctl test. Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
RE: Linux emulation: acd0a is not a cooked ioctl CDROM
Lowell wrote: Lucky Green [EMAIL PROTECTED] writes: Nick wrote: Checking /dev/cdrom for cdrom... Testing /dev/cdrom for cooked ioctl() interface /dev/acd0a is not a cooked ioctl CDROM. Testing /dev/cdrom for SCSI interface /dev/cdrom is not a SCSI device That doesn't look quite right; CDROM devices are usually accessed as /dev/acd0c in FreeBSD. Only if they're ATAPI drives. Which this poster said he had. He also said he was using cdparanoia, which is, as the error message said, specific to SCSI drives. [On Linux, ATAPI drives are supported by making them look like SCSI drives, so it sort of works with cdparanoia, but on FreeBSD ATAPI drives are supported directly.] Do you believe that the ATAPI/CAM patches at http://www.cuivre.fr.eu.org/~thomas/atapicam/ might make cdparanoia compatible with an ATAPI drive on FreeBSD? I guess that would mean the patches would have to provide the cooked ioctl that cdparanoia wants. I would be willing to install -CURRENT if that will make cdparanoia work. Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Linux emulation: acd0a is not a cooked ioctl CDROM
Configuration: FreeBSD 4.6.2 with latest patches and all ports cvsupped as of a few days ago. ATAPI CDROM. I am in the process of ripping a large CD collection. Fidelity is paramount. By all accounts, the ripper of choice for audiophiles is cdparanoia. Unfortunately, according to their web page, there is no FreeBSD port of cdparanoia, even though OpenBSD and NetBSD ports exist. I therefore installed the Redhat Linux RPM of cdparanoia. The RPM installed without errors and I am able to execute the Linux binary just fine. However, cdparanoia seems to be unable to communicate with my CDROM drive. Here is the error message: #./cdparanoia -vsQ cdparanoia III release 9.7 (December 13, 1999) (C) 1999 Monty [EMAIL PROTECTED] and Xiphophorus Report bugs to [EMAIL PROTECTED] http://www.xiph.org/paranoia/ Checking /dev/cdrom for cdrom... Testing /dev/cdrom for cooked ioctl() interface /dev/acd0a is not a cooked ioctl CDROM. Testing /dev/cdrom for SCSI interface /dev/cdrom is not a SCSI device Checking /dev/hd0 for cdrom... [... Trying a bunch of devices elided in the interest of brevity]. No cdrom drives accessible to root found. - At this point, cdparanoia dumps core. Now I have no idea what a cooked ioctl is and Google was of no help, but I suspect that somehow the Linux emulation layer in FreeBSD does not provide cdparanoia with a device it knows how to talk to. Does anybody here have any idea how to fix/debug this problem? Thanks in advance, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Mouse jumping all over the place in X
I have seen the following problem many times over the years with a number of mice, but never found a fix other than using a different mouse. I just bought a Memorex MX4200 PS/2 optical mouse. When attempting to use X with the new mouse, the pointer jumps all over the place upon the slightest movement of the mouse. The relevant entry of XF86config follows: Section InputDevice Identifier Mouse0 Driver mouse Option Protocol MouseSystems Option Device /dev/sysmouse EndSection I am running FreeBSD 4.6.2 with the latest patches and ports, including X, cvsupped yesterday. I re-ran XFree86 -configure, which lead to the same XF86config entry as above. Does anybody here know the fix for this, as I heard it sometimes called, supermouse problem? Or do I just need to buy another mouse? Thanks, --Lucky To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Tunefs tutorial?
Is there a tutorial that explains the various tunefs options, ideally with examples as to what the optimal settings are for various drives? I read the man page, but it just shows what the various options can do, not what their ideal settings are under various circumstances. Thanks, --Lucky Green To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
