Re: SCSI troubles still
Hi, thanks for your answer. I have U320 cable with active terminator on its and. But I could try some other cable. Thanks for idea. Tomas Randa David Vastine wrote: On Jul 10, 2005, at 3:51 PM, Tomas Randa wrote: Hi all, I am writing you again because I have still problems with my FreeBSD BOX (5.4 p4) with AHD and Seagate 15k4 drive. System is based on Via K8T890 / Athlon64, i386 distribution of FreeBSD. I have *latest firmware* in drive and controller ( ST336754LW 003 and Adaptec 29320 4.30.0), but still have sometime problems like this on console: When this dumping start, my system have a huge load - about 150! I have no idea what to do next, please help someone. Is Ultra320 from Seagate broken? Should I try to slow down the disk bus speed to 160MB/s ? Thanks! Tomas Randa Is the drive properly terminated? When I got errors like those it was due to the drive not being terminated.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.4-RELEASE-p4: shutdown hangs after rebuiding gmirror
Hi. I am running FreeBSD 5.4-RELEASE-p4 on a sun V20Z. It has two seagate ST373307LC disks. The disks are mirrored with gmirror: NameStatus Components mirror/raid1 COMPLETE da0 da1 I unplugged one of the disks, then rebooted to see if it would boot from just the one disk. Of course there was no problem there. I then inserted the other disk back in, followed by camcontrol rescan all gmirror forget raid1 gmirror insert raid1 da1 After a while the mirror was OK again. I then rebooted for a second time. But the machine would not come up. The last lines printed on the console were Syncing disks, vnodes remaining...1 1 0 1 1 0 0 0 done No buffers busy after final sync Uptime: 55m39s GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed. GEOM_MIRROR: Device raid1 destroyed. So it was stuck somewhere in the shutdown sequence between the gmirror destruction and the "Shutting down ACPI" bit. Sending a break to the console did not produce a DDB prompt, whereas during normal operation it would. I had to power-cycle to get the boot to work again. If I leave the disks alone, rebooting does not hang the machine. This is a bit of a nuisance. Who has any idea where to look to troubleshoot this? Cheers Michiel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror, sparc and SCSI problems
On 7/10/05, Johannes Verwijnen <[EMAIL PROTECTED]> wrote: > On Jul 9, 2005, at 19:36, Chris Hodgins wrote: > > It seems that gmirror does not give us any partitions. A listing of > > the mirror directory shows only the gm0 node even though da0 is > > partitioned. When mounting the mirror it seems that /dev/mirror/gm0 > > only represents the root partition. How can we get the mirror to > > recognise the other partitions? > > I remember (vaguely)) this kind of problem, where when trying to > mirror a whole disk, you'd only get the first slice. Have you tried > mirroring the slices (da0s1 etc) separately? > > -- > duvin > > Firstly thanks for all the suggestions. We managed to build the mirrors by using the suggestion above mirroring the slices separately. Unfortunetly, although the mirrors were created properly the filesystems are constantly suffering from inconsistencies and fsck actually appears to be segfaulting. We have decided not to pursue this any further for the moment, however we are prepared to allow access to the machine should anyone wish to try and sort out this incompatibility with gmirror and sparc. Included below is a brief logfile of a reboot after fsck'ing all of the mirrored partitions. # reboot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done No buffers busy after final sync Uptime: 5m23s GEOM_MIRROR: Device gm0e: provider mirror/gm0e destroyed. GEOM_MIRROR: Device gm0e destroyed. GEOM_MIRROR: Device gm0d: provider mirror/gm0d destroyed. GEOM_MIRROR: Device gm0d destroyed. GEOM_MIRROR: Device gm0b: provider mirror/gm0b destroyed. GEOM_MIRROR: Device gm0b destroyed. GEOM_MIRROR: Device gm0a: provider mirror/gm0a destroyed. GEOM_MIRROR: Device gm0a destroyed. Rebooting... Resetti LOM event: +38d+3h37m11s host reset ng ... \u Processor Speed = 648 MHz Baud rate is 9600 8 Data bits, 1 stop bits, no parity (configured from lom) Firmware CORE Sun Microsystems, Inc. @(#) core 1.0.12 2002/01/08 13:00 Software Power ON Verifying NVRAM...Done Bootmode is 0 [New I2C DIMM address] MCR0 = 57b2ce06 MCR1 = 80008000 MCR2 = cf3000ff MCR3 = a0cf Ecache Size = 512 KB Clearing E$ Tags Done Clearing I/D TLBs Done Probing memory Done MEMBASE=0x4000 MEMSIZE=0x2000 Clearing memory...Done Turning ON MMUs Done Copy ROM to RAM (170040 bytes) Done Orig PC=0x1fff0007e44 New PC=0xf0f07e9c Processor Speed=648MHz Looking for Dropin FVM ... found Decompressing Client Done Transferring control to Client... ttya initialized Reset Control: BXIR:0 BPOR:0 SXIR:0 SPOR:1 POR:0 Probing upa at 1f,0 pci pci pci Probing upa at 0,0 SUNW,UltraSPARC-IIe SUNW,UltraSPARC-IIe (512 Kb) Loading Support Packages: kbd-translator Loading onboard drivers: ebus flashprom eeprom idprom SUNW,lomh Probing /[EMAIL PROTECTED],1 Device 3 pmu i2c temperature dimm dimm i2c-nvram idprom motherboard-fru fan-control lomp Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 1024 MB memory installed, Serial #53833010. Ethernet address 0:3:ba:35:6d:32, Host ID: 83356d32. Executing last command: boot /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a File and args: >> FreeBSD/sparc64 boot block Boot path: /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a Boot loader: /boot/loader Console: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 ([EMAIL PROTECTED], Sun May 8 07:16:15 UTC 2005) bootpath="/[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0x3d8908+0x47c78 syms=[0x8+0x50b80+0x8+0x45260] /boot/kernel/geom_mirror.ko text=0x21558 data=0x5b0+0x18 syms=[0x8+0x1638+0x8+0x10da] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... nothing to autoload yet. jumping to kernel entry at 0xc004. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RELEASE #0: Sun May 8 22:21:34 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "tick" frequency 64800 Hz quality 1000 real memory = 1073741824 (1024 MB) avail memory = 1025818624 (978 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU) nexus0: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A pcib0 dvma: DVMA map: 0xc000 to 0xc3ff pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 ebus0: mem 0xf100-0xf17f,0xf000-0xf0ff at device 12.0 on pci1 ebus0: : incomplete ebus0: addr 0x10-0x1f (no driv
Re: Today's RELENG_5_4 and 'lock cmpxchgl'
On Sun, Jul 03, 2005 at 10:38:58AM +0200, Philippe PEGON wrote: > >The panic appears to be an instance of a known bug in 5.4 (and > >INVARIANTS will not fix it, but may just delay the inevitable by > >changing timings). See Doug White's recent emails which point to a > >patch you should test. > > If you think about this mail : > > http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016165.html > > and follow the thread, you will see that this patch doesn't solve the > problem. > The last mail which I can see from doug white about this problem is : > > http://lists.freebsd.org/mailman/htdig/freebsd-stable/2005-June/016495.html > > for the moment, it seems that there is no solution for 5.x Well, the bug hasn't bitten me since I reactivated INVARIANTS, so I'll keep this workaround active for now. :-/ If I don't enable INVARIANTS, as soon as I start 'screen', it's a panic. Marc pgppHF0f9m9aV.pgp Description: PGP signature
FYI - RELENG_6 branch has been created.
Just a quick note to say that as part of the FreeBSD-6.0 Release Cycle the RELENG_6 branch tag has just been created in the CVS repository. In preparation for the release some places in the tree now say that this branch is -STABLE but there is still work to do before this branch will be ready for release. People who are not in a position to help work out the remaining bugs in the RELENG_6 branch as we work towards the FreeBSD-6.0 Release should definitely continue using RELENG_5_4 or RELENG_5 as appropriate. Thanks. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Fatal trap 18: integer divide fault while in kernel mode
Hi,
got the following panic while plugging an external 400gb disk via USB2.0
in to an SMP machine.
Dump and debugging kernel are available.
FreeBSD haakonia.hitnet.RWTH-Aachen.DE 5.4-STABLE FreeBSD 5.4-STABLE #85: Thu
Jun 16 09:45:23 CEST 2005
[EMAIL PROTECTED]:/usr/home/build/usr/home/build/src/sys/LORIEN i386
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc0481d35 in db_fncall (dummy1=0, dummy2=0, dummy3=1999, dummy4=0xd5444590
" ®|À\022")
at /usr/home/build/src/sys/ddb/db_command.c:531
#2 0xc0481ac2 in db_command (last_cmdp=0xc07ca524, cmd_table=0x0,
aux_cmd_tablep=0xc07906e0,
aux_cmd_tablep_end=0xc07906e4) at
/usr/home/build/src/sys/ddb/db_command.c:349
#3 0xc0481bd5 in db_command_loop () at
/usr/home/build/src/sys/ddb/db_command.c:455
#4 0xc0483d15 in db_trap (type=18, code=0) at
/usr/home/build/src/sys/ddb/db_main.c:221
#5 0xc059915e in kdb_trap (type=0, code=0, tf=0x1) at
/usr/home/build/src/sys/kern/subr_kdb.c:468
#6 0xc0725824 in trap_fatal (frame=0xd544472c, eva=0)
at /usr/home/build/src/sys/i386/i386/trap.c:812
#7 0xc07252a2 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -557797922,
tf_ebp = -716945424, tf_isp = -716945576, tf_ebx = -557797921, tf_edx = 0,
tf_ecx = 0, tf_eax = 1, tf_trapno = 18, tf_err = 0, tf_eip = -1066185909, tf_cs
= 8, tf_eflags = 66118, tf_esp =
-1068481083, tf_ss = -1045757696}) at
/usr/home/build/src/sys/i386/i386/trap.c:622
#8 0xc071023a in calltrap () at
/usr/home/build/src/sys/i386/i386/exception.s:140
#9 0x0018 in ?? ()
#10 0x0010 in ?? ()
#11 0x0010 in ?? ()
#12 0x0001 in ?? ()
#13 0xdec0adde in ?? ()
#14 0xd54447f0 in ?? ()
#15 0xd5444758 in ?? ()
#16 0xdec0addf in ?? ()
#17 0x in ?? ()
#18 0x in ?? ()
#19 0x0001 in ?? ()
#20 0x0012 in ?? ()
#21 0x in ?? ()
#22 0xc0734b4b in __qdivrem (uq=Unhandled dwarf expression opcode 0x93
) at /usr/home/build/src/sys/libkern/qdivrem.c:97
#23 0xc0734fde in __udivdi3 (a=Unhandled dwarf expression opcode 0x93
) at /usr/home/build/src/sys/libkern/udivdi3.c:47
#24 0xc043fd45 in cam_calc_geometry (ccg=0xd54448bc, extended=1)
at /usr/home/build/src/sys/cam/cam.c:376
#25 0xc0514394 in umass_cam_action (sim=0xc457c4c0, ccb=0xd54448bc)
at /usr/home/build/src/sys/dev/usb/umass.c:2580
#26 0xc0444e3e in xpt_action (start_ccb=0xd54448bc) at
/usr/home/build/src/sys/cam/cam_xpt.c:3076
#27 0xc044d5d0 in dasetgeom (periph=0x0, block_len=0,
maxsector=16051020244679962078)
at /usr/home/build/src/sys/cam/scsi/scsi_da.c:1741
#28 0xc044cca8 in dadone (periph=0xc292a680, done_ccb=0xc1aa9800)
at /usr/home/build/src/sys/cam/scsi/scsi_da.c:1395
#29 0xc044942f in camisr (V_queue=0xc07c92a0) at
/usr/home/build/src/sys/cam/cam_xpt.c:7072
#30 0xc05635f2 in ithread_loop (arg=0xc1a08e00) at
/usr/home/build/src/sys/kern/kern_intr.c:547
#31 0xc0562576 in fork_exit (callout=0xc0563480 , arg=0x0,
frame=0x0)
at /usr/home/build/src/sys/kern/kern_fork.c:791
#32 0xc071029c in fork_trampoline () at
/usr/home/build/src/sys/i386/i386/exception.s:209
- Christian
--
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
pgpUFP8nPyhqf.pgp
Description: PGP signature
We focus on OEM and Retail Box for Microsoft, Adobe, Macromedia, Corel, Symantec and more.
Loaded with technology for business and home. http://itia.azw7vra372shpba.shoatmache.com Everywhere I go I find a poet has been there before me. The first wealth is health. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI - RELENG_6 branch has been created.
On Mon, 11 Jul 2005, Ken Smith wrote: Just a quick note to say that as part of the FreeBSD-6.0 Release Cycle the RELENG_6 branch tag has just been created in the CVS repository. In preparation for the release some places in the tree now say that this branch is -STABLE but there is still work to do before this branch will be ready for release. People who are not in a position to help work out the remaining bugs in the RELENG_6 branch as we work towards the FreeBSD-6.0 Release should definitely continue using RELENG_5_4 or RELENG_5 as appropriate. As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the release candidate series in order to assist in debugging problems. However, anyone running RELENG_6 until that time should be aware that these debugging features result in a loss of 1/2 or more performance for many common workloads. Depending on workload and hardware, this might or might not present a problem for your environment -- the features are invaluable in diagnosing problems, however, so if it's possible to leave them on in testing, that would be useful. Obviously, tesing without them is also desired, as they significantly perturb timing, but the first question you'll get is "can you reproduce them with debugging features enabled?" :-). Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI - RELENG_6 branch has been created.
At 05:04 PM 11/07/2005, Robert Watson wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Apart from the kernel settings, what other debug settings need to be turned off ? i.e. How do I turn off malloc debugging ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI - RELENG_6 branch has been created.
Mike Tancsa wrote: At 05:04 PM 11/07/2005, Robert Watson wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Apart from the kernel settings, what other debug settings need to be turned off ? i.e. How do I turn off malloc debugging ? ---Mike ln -s aj /etc/malloc.conf Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FYI - RELENG_6 branch has been created.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I ran into two issues so far. This is a box that has something like 300 programs on it that I use to test various and sundry things. Japanese input (using kinput2 and canna) stopped working. Last time, I was able to fix this with the new port /usr/ports/misc/localedata, but in this case I wasn't. (I think this has to do with the changes in LC_CTYPE). However, reinstalling the two xterms that I use with Japanese, rxvt-devel and ja-aterm fixed this problem. (The risky fix is to add a libc.5.so libc.6.so to /etc/libmap.conf. This fixes it too, but I suspect risks breaking many other things.) The other problem that will possibly affect more people is that SpamAssassin stopped working properly. This isn't a server, simply a workstation, using getmail and maildrop. I would get the following error Delivery error (command maildrop 65199 error (0, razor2 check skipped: No such file or directory IO::Socket::INET: connect: Operation not permitted ...propagated at /usr/local/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin/Dns.pm line 447.)) msg 1/1 (1422 bytes), delivery error (command maildrop 65199 error (0, razor2 check skipped: No such file or directory IO::Socket::INET: connect: Operation not permitted ...propagated at /usr/local/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin/Dns.pm line 447.)) 1 messages retrieved, 0 skipped Thinking that it was a simple perl thing and perhaps also connected with the libc.5 and 6, I first did a portupgrade -fRr of SpamAssassin. This didn't fix the problem. Eventually (and I don't have enough knowledge to know why this worked) I did another portupgrade -f of perl, then did a pkg_delete of SpamAssassin and all B and R deps save for perl. I then reinstalled SpamAssassin with the port reinstalling the deps. Then it worked. Unfortunately, I don't have another machine to use as a test box, but if this problem does affect many people, it would defintely hinder some mail server upgrades. :) I repeat however, the box in question has close to 300 programs on it, so that we can see what problems we might run into with a variety of servers. - -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Anya: Men like sports. I'm sure of it. Xander: Yes. Men like sports. Men watch the action movie, they eat of the beef, and they enjoy to look at the bosoms. A thousand years of avenging our wrongs, and that's all you've learned? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC0zEd+lTVdes0Z9YRAlhkAJ93PfOM+KyDUAK8Ltcd1wRBO/6HvQCgxLC3 hIQkiX5+B/UJ5LF2hvf4uCc= =qUCI -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 Installer + Promise FT100TX2 = Loader crash
On Saturday 25 June 2005 21:26, Daniel O'Connor wrote: > Hmm I see.. I know it works OK with 4. as I have installed plenty > of systems like that. I will try some earlier 5.x releases (say, boot only > ISOs) and see how it goes. - 5.1 works. - 5.2 insta-reboot. - 5.2.1 BTX halted - 5.3 insta-reboot. - 5.4 insta-reboot. 5.4 also spins in a loop forever printing register dumps, not sure if 5.2-5.3 do it as well. The 5.2.1 BTX error says.. Building the boot loader arguments Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.1 Console: internal video/keyboard BIOS CD is cd0 BIOS driver A: is disk0 BIOS 628kB/523200kB available memory FreeBSD/i386 bootstrap loadaer, Revision 1.1 ([EMAIL PROTECTED], Mon Feb 23 18:35:51 GMT 2004) | int=000d err= efl=00030282 eip=fffe eax=42ad ebx= ecx=0001 edx=009f esi=0008 edi=000c ebp= esp=0404 cs= ds=45e5 es=4bc8fs= gs= ss=9b57 cs:eip=bb 00 00 00 00 c7 45 d8-00 00 00 00 8b 55 d4 66 83 7a 2c 00 74 27 0f b7-52 2c 90 8d b4 26 00 00 ss:eip=90 a4 00 f0 46 02 4a 91-00 00 46 00 00 00 00 00 9f 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted > > That fact that it *sometimes* works is interesting - I am curious to see > > if you can reproduce this (say try 10 - 15 times). > > OK, well I'll try it a few times and see :) I tried this quite a number of times but haven't seen it succeed yet. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpv4N1AHDqxm.pgp Description: PGP signature
tcp troughput weirdness
while checking out the quality of a switch, I came about a very disturbing dicovery: FreeBSD <-> Linux througput is MUCH better than FreeBSD <-> FreeBSD Setup: 2 blades in the same bladeserver, A running FreeBSD 5.4, B running Linux C is running FreeBSD 5.4 all are connected at 1gb. A -+ (FreeBSD) | B -+ (Linux) | [switch] | + [router] --- C (FreeBSD) A & B are on the same Vlan. iperf results: Interval Transfer Bandwidth A <=> B 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec A <=> C 0.0-10.0 sec 515 MBytes 432 Mbits/sec B <=> C 0.0-10.0 sec 1.07 GBytes 918 Mbits/sec I've run the tests several times, and the numbers are very similar, so BIG Question: is there anything that can be tunned on the FreeBSD to better the throughput? danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp troughput weirdness
we need more data points - did you test tcp or udp ? who is sourcing data ? are the bandwidth symmetric (i.e. A-> same as B -> A ? cheers luigi On Tue, Jul 12, 2005 at 09:21:13AM +0300, Danny Braniss wrote: > while checking out the quality of a switch, I came about a very disturbing > dicovery: FreeBSD <-> Linux througput is MUCH better than FreeBSD <-> FreeBSD > > Setup: > 2 blades in the same bladeserver, A running FreeBSD 5.4, B running Linux > C is running FreeBSD 5.4 > all are connected at 1gb. > > A -+ (FreeBSD) > | > B -+ (Linux) > | > [switch] > | > + [router] --- C (FreeBSD) > A & B are on the same Vlan. > > iperf results: > Interval Transfer Bandwidth > > A <=> B 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec > > A <=> C 0.0-10.0 sec 515 MBytes 432 Mbits/sec > > B <=> C 0.0-10.0 sec 1.07 GBytes 918 Mbits/sec > > I've run the tests several times, and the numbers are very similar, > so BIG Question: is there anything that can be tunned on the FreeBSD to > better the throughput? > > danny > > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp troughput weirdness
> we need more data points - > did you test tcp or udp ? i used iperf: Client connecting to x-dev, TCP port 5001 TCP window size: 65.0 KByte (WARNING: requested 64.0 KByte) > who is sourcing data ? all, I tried all combinations, and the numbers are very similar to the ones i posted. > are the bandwidth symmetric (i.e. A-> same as B -> A ? yes, theys are all in the same floor, fisical distance is a few meters. i also tried other similar boxes and the freebsd thoughput is very similar, so i doubt it that switches or hardware is involved. > cheers > luigi thanks, danny > > On Tue, Jul 12, 2005 at 09:21:13AM +0300, Danny Braniss wrote: > > while checking out the quality of a switch, I came about a very disturbing > > dicovery: FreeBSD <-> Linux througput is MUCH better than FreeBSD <-> > > FreeBSD > > > > Setup: > > 2 blades in the same bladeserver, A running FreeBSD 5.4, B running Linux > > C is running FreeBSD 5.4 > > all are connected at 1gb. > > > > A -+ (FreeBSD) > >| > > B -+ (Linux) > >| > > [switch] > > | > > + [router] --- C (FreeBSD) > > A & B are on the same Vlan. > > > > iperf results: > > Interval Transfer Bandwidth > > > > A <=> B 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec > > > > A <=> C 0.0-10.0 sec 515 MBytes 432 Mbits/sec > > > > B <=> C 0.0-10.0 sec 1.07 GBytes 918 Mbits/sec > > > > I've run the tests several times, and the numbers are very similar, > > so BIG Question: is there anything that can be tunned on the FreeBSD to > > better the throughput? > > > > danny > > > > > > > > ___ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
