Re: Merged em driver
Jack Vogel wrote: The next driver I that I release via Intel channels is going to merge the code for 6 and 7. I was thinking that I could check that into the tip and it would make the most current version buildable on either RELEASE, was wondering if that is looked upon favorably or not? I have code ready to do that if getting it into 7.0 would be desireable. I think that if the change is not quite intrusive (e.g. add some ifdef blocks rather than restructuring the code heavily) then it would be desirable to have it hit the tree before we branch RELENG_7. However, if the change would be very late then it would be better to have it delayed and only backport important fixes in a case-by-case manner. My $0.02 :-) Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: ntpd on a NAT gateway seems to do nothing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew Reilly wrote: On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote: On 2007-Jul-24 16:00:08 +0100, Pete French [EMAIL PROTECTED] wrote: Yes it does. The major difference is that ntpd will use a source port of 123 whilst ntpdate will use a dynamic source port. Is that behaviour that can be defeated? If it uses a fixed source port, then multiple ntpd clients behind a nat firewall will be competing for the same ip quadtuple at the NAT box. (Or does ipnat or pf have the ability to fake different source addresses?) NAT gateways will remap the source port number as necessary to disambiguate the different hosts. Although NTP defaults to using port 123 on both the source and destination ends, it only *has* to use port 123 on the destination (server) end. The admin can override that behaviour by using 'restrict addr ntpport' in ntp.conf if required. NTP queries performed via user programs like ntpq(8) and ntpdc(8) always use an arbitrary high numbered source port. There's a similar configuration trick used with the DNS, except in that case, it works in the opposite sense: DNS queries will use an arbitrary high numbered source port by default, but you can configure named to force use of port 53 as the source port. Obviously this only applies to the server-to-server queries performed by recursive DNS servers -- as far as I know, there's no way to force the local resolver library on a particular machine to use a specific source port. In any case, the justification for forcing UDP packets to use a specific source port disappears when you use a modern stateful firewall like any of the three (pf, ipfw, ipf) supplied with FreeBSD. (I've had what I think is this problem with a VPN setup, where only one client behind the NAT firewall could run the VPN client at a time, because the VPN protocol used a fixed port and UDP. Maybe my NAT rules need more sophistication? I don't pay all that much attention to it...) Indeed. For instance, in the case of IPSec there is a special high-numbered port reserved for use exchanging keys when transiting NAT gateways. See http://www.ietf.org/rfc/rfc3947.txt for the gory details. Note that other VPN packages such as OpenVPN work in a different way and shouldn't hit this particular hurdle, or at least, not in the same way. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpvw38Mjk52CukIwRCEwOAKCA7xelVOzskL4BXyFiplIwwJTJPgCfVWb5 l6Kfk7Sx1glV44FBBL8oqkU= =GeJ8 -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: ntpd on a NAT gateway seems to do nothing
Andrew Reilly wrote: Peter Jeremy wrote: The major difference is that ntpd will use a source port of 123 whilst ntpdate will use a dynamic source port. Is that behaviour that can be defeated? If it uses a fixed source port, then multiple ntpd clients behind a nat firewall will be competing for the same ip quadtuple at the NAT box. Usually the clients behind the NAT gateway use the ntpd running on the gateway itself, not any servers beyond. So NTP queries never have to be forwarded across the gateway, so they're not subject to NAT translation at all. The gateway rather acts as server and client at the same time. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with Hitachi 1TB SATA drives
Jeremy Chadwick wrote: * Hard disks are growing in capacity, but are not growing in physical size. We're pushing 1TB in a 3.5 form factor. And the same applies to laptop (2.5) drives. The margin of error continues to increase as we try to cram more and more data in such a small medium. I personally would *love* to see drives go back to using a 5.25 form factor, especially for large capacity disks, since chances are it means higher reliability (read: less chance of error). As far as reliability goes, I agree. However, the problem is, you cannot make 5.25 disks spin at 10 or 15 krpm. Well, maybe you can, but it's a hell of an engineering problem. Even 7200 rpm isn't trivial to do for such large discs. And who wants to buy a slow 3600 rpm 5.25 drive? Apart from that, the larger radius also means slower end-to-end movement for the heads. * All this leads me to the topic of backups. Hard disks are growing in capacity at a rate which the backup industry cannot follow. It's getting to the point where you have to buy hard drives to back up the data on other hard drives, but anyone with half a brain knows RAID is not a replacement for backups. Correct, RAID and backups are completely different. But you can use disk drives for both. I solved my backup problem by putting a hot-swap ATA frame into my home server (they're pretty cheap nowadays), and using a bunch of ATA disks as removable media. It's just like tape backups, but much cheaper, faster and easier to use. It beats every tape technology hands down. going to sit around once a week backing up a terabyte of data to ~120 dual-layer 8.5GB DVDs? I wouldn't even start thinking about considering that. The closest thing out there right now is a product from IOMega called REV, which (at most) offers 70GB of storage per disk, or 140GB with compression. A new IOMega REV (which includes one 70GB disk) costs US$600 MSRP. You read that right. Ugh. For US$600 you get four 400 GB disk drives, including four trays and one frame (hot-swap capable). That's 1.6 TB of backup capacity. Compare that to 70 GB. I also guess that that REV thing is much slower than an ATA disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd on a NAT gateway seems to do nothing
On 2007-Jul-25 10:30:25 +1000, Andrew Reilly [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote: On 2007-Jul-24 16:00:08 +0100, Pete French [EMAIL PROTECTED] wrote: Yes it does. The major difference is that ntpd will use a source port of 123 whilst ntpdate will use a dynamic source port. Is that behaviour that can be defeated? I don't believe so. If it uses a fixed source port, then multiple ntpd clients behind a nat firewall will be competing for the same ip quadtuple at the NAT box. You might be better off running ntpd on the firewall and having the inside hosts sync to it. (Or does ipnat or pf have the ability to fake different source addresses?) All NAT tools I've seen have the ability to either use multiple external addresses or re-write the source port to avoid clashes. Note that, by default, ntpd doesn't care about the source port of incoming packets (this can be controlled with the 'ntpport' option to 'restrict'). (I've had what I think is this problem with a VPN setup, where only one client behind the NAT firewall could run the VPN client at a time, because the VPN protocol used a fixed port and UDP. Maybe my NAT rules need more sophistication? I don't pay all that much attention to it...) I suspect that either your NAT rules need to allow source port re-writing or the VPN protocol is fussier about having the source port. -- Peter Jeremy pgp317m8M4Z7o.pgp Description: PGP signature
Re: ntpd on a NAT gateway seems to do nothing
You might be better off running ntpd on the firewall and having the inside hosts sync to it. That would be nice - except my problem is that the firewal is the only one on which ntp *doest* run! :-) Thanks for all the other suggestions - will take a look a them later today and see if I can track this down. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
lagg on RELENG_6 is currently broken due to subtle differences that wernt taken into account when it was MFCd. Can you please test this patch. Erp! Do you have any mor einfo on tyhis - what kinds of things does this break ? Since lagg arrived I have deployed it on all our production machines. It seems to work fine for me, I have to say, but I would like to know what problems I might be about to encounter. Will apply and test your patch (though having seen no problems anyway I am not sure how useful that will be). -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
bind exploit, patch expected?
I assume the security team are already working on this but cant hurt to ask: http://www.net-security.org/secworld.php?id=5366 Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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: bind exploit, patch expected?
At 10:50 AM 7/25/2007, Steven Hartland wrote: I assume the security team are already working on this but There was a posting on the security list already about it. http://lists.freebsd.org/pipermail/freebsd-security/2007-July/004411.html ---Mike cant hurt to ask: http://www.net-security.org/secworld.php?id=5366 Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.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] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bind exploit, patch expected?
Steven Hartland wrote: I assume the security team are already working on this but cant hurt to ask: Before you ask questions on a public list it's generally considered polite to do a little checking yourself, especially in an open source project. As Mike pointed out, the secteam had already addressed this issue on -security, and I had already followed up in detail regarding the upgrade plans. In addition, at the time you posted the updates had all been done in the ports, HEAD (-current), and RELENG_[56] (5 and 6-stable). In any case, it's good that you're on top of your security announcements, and I'm glad to say that this time anyway we're one step ahead. :) Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks?
Scott Long wrote: Howard Goldstein wrote: Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem mounted with softupdates, remounted after each test P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller detects these SATA-II drives inexplicably as SATA-I ICH5 only support SATA-1. Dang. Does anyone yield SATA-II speeds with the a PCI controller? I'm not sure if 25-30MB/s is even possible with regular PCI Of course after this I used gmirror... Just so we're clear, the ICH5 doesn't have any firmware and doesn't actually do any RAID operations. What is has is hook into the system BIOS during boot. That hook allows the BIOS to do RAID-like operations during boot, until the OS takes over control of the devices. After that, it's up to the OS to do all the RAID work. The 'ar' driver is still software RAID, just like gmirror. What you've effectively done merely compare the performance of one software RAID stack to another. That's certainly an interesting comparison, but maybe not exactly what you had in mind. It's helpful - thank you. Do you think I'm correct in assuming the interface is pretty much saturated at this point and if I wanted additional speed I'd need to start thinking bringing in additional or faster interfaces? (ps - apologies in advance if this comes through in html format) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
On Thu, Jul 26, 2007 at 01:02:06AM +0100, Pete French wrote: All zeros! very interesting - am surprised the switch didn't kick up a fuss about that. Well, patch applied and rebooting... ...and now all my outgoing packets have the correct MAC address as expected on them. I alos notice that I am now only seeing packets destined for the appropriate machine comming out of my switch. Before the patch I could see all the packets for all machine using tcpdup. Great, thanks for testing. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks?
Scott Long wrote: Howard Goldstein wrote: Scott Long wrote: Howard Goldstein wrote: Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem mounted with softupdates, remounted after each test P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller detects these SATA-II drives inexplicably as SATA-I ICH5 only support SATA-1. Dang. Does anyone yield SATA-II speeds with the a PCI controller? I'm not sure if 25-30MB/s is even possible with regular PCI Even PCI-33 should be able to sustain about 100MB/s, enough to handle a single disk drive. Many controller are PCI-X or PCIe now, which has plenty of bandwidth for 4-8 drives. Sorry I dropped a zero as my stupid test showed 76-77MB/s. I think I should perhaps throw in the towel as the manual for this old P4P800 claims its 32 bit PCI 2.2 support ... 133MB/s maximum Of course after this I used gmirror... Just so we're clear, the ICH5 doesn't have any firmware and doesn't actually do any RAID operations. What is has is hook into the system BIOS during boot. That hook allows the BIOS to do RAID-like operations during boot, until the OS takes over control of the devices. After that, it's up to the OS to do all the RAID work. The 'ar' driver is still software RAID, just like gmirror. What you've effectively done merely compare the performance of one software RAID stack to another. That's certainly an interesting comparison, but maybe not exactly what you had in mind. It's helpful - thank you. Do you think I'm correct in assuming the interface is pretty much saturated at this point and if I wanted additional speed I'd need to start thinking bringing in additional or faster interfaces? You should be able to sustain at least 70MB/s on a single modern drive with SATA-1 or SATA-2. If you're not getting that then something in the driver or the application is getting in the way. Even with the, um, problems that SiI controllers are famous for, you should be able to sustain a decent data rate on a single drive. Thank you, Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks?
Howard Goldstein wrote: Scott Long wrote: Howard Goldstein wrote: Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem mounted with softupdates, remounted after each test P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller detects these SATA-II drives inexplicably as SATA-I ICH5 only support SATA-1. Dang. Does anyone yield SATA-II speeds with the a PCI controller? I'm not sure if 25-30MB/s is even possible with regular PCI Even PCI-33 should be able to sustain about 100MB/s, enough to handle a single disk drive. Many controller are PCI-X or PCIe now, which has plenty of bandwidth for 4-8 drives. Of course after this I used gmirror... Just so we're clear, the ICH5 doesn't have any firmware and doesn't actually do any RAID operations. What is has is hook into the system BIOS during boot. That hook allows the BIOS to do RAID-like operations during boot, until the OS takes over control of the devices. After that, it's up to the OS to do all the RAID work. The 'ar' driver is still software RAID, just like gmirror. What you've effectively done merely compare the performance of one software RAID stack to another. That's certainly an interesting comparison, but maybe not exactly what you had in mind. It's helpful - thank you. Do you think I'm correct in assuming the interface is pretty much saturated at this point and if I wanted additional speed I'd need to start thinking bringing in additional or faster interfaces? You should be able to sustain at least 70MB/s on a single modern drive with SATA-1 or SATA-2. If you're not getting that then something in the driver or the application is getting in the way. Even with the, um, problems that SiI controllers are famous for, you should be able to sustain a decent data rate on a single drive. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
On Wed, Jul 25, 2007 at 10:42:21PM +0400, Alexey Karagodov wrote:
patch did not help ...
ifconfig:
lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 10.0.0.1 netmask 0x broadcast 10.0.255.255
inet 10.0.0.2 netmask 0x broadcast 10.0.255.255
ether XX:XX:XX:XX:XX:XX
media: Ethernet autoselect
status: active
laggproto lacp
laggport: em1 flags=1cACTIVE,COLLECTING,DISTRIBUTING
laggport: em0 flags=1cACTIVE,COLLECTING,DISTRIBUTING
i was tried to change laggproto, it doesn't help.
i can NOT increase MTU on lagg interface above 1500 and on vlan interface
above lagg's MTU -4 .
also i've increased MTU on both ems to 9000 and after that i still can't
increase MTU on lagg interface above 1500
please, HELP ...
Please test this attached patch, note it includes the previous change
too.
regards,
Andrew
Index: if_lagg.c
===
RCS file: /home/ncvs/src/sys/net/if_lagg.c,v
retrieving revision 1.11.2.3
diff -u -p -r1.11.2.3 if_lagg.c
--- if_lagg.c 12 Jul 2007 20:40:24 - 1.11.2.3
+++ if_lagg.c 26 Jul 2007 00:35:24 -
@@ -78,7 +78,8 @@ eventhandler_tag lagg_detach_cookie = NU
static int lagg_clone_create(struct if_clone *, int);
static voidlagg_clone_destroy(struct ifnet *);
static voidlagg_lladdr(struct lagg_softc *, uint8_t *);
-static int lagg_capabilities(struct lagg_softc *);
+static voidlagg_capabilities(struct lagg_softc *);
+static voidlagg_mtu(struct lagg_softc *);
static voidlagg_port_lladdr(struct lagg_port *, uint8_t *);
static voidlagg_port_setlladdr(void *, int);
static int lagg_port_create(struct lagg_softc *, struct ifnet *);
@@ -319,33 +320,62 @@ lagg_lladdr(struct lagg_softc *sc, uint8
if (memcmp(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN) == 0)
return;
+ bcopy(lladdr, IFP2ENADDR(ifp), ETHER_ADDR_LEN);
bcopy(lladdr, IF_LLADDR(ifp), ETHER_ADDR_LEN);
/* Let the protocol know the MAC has changed */
if (sc-sc_lladdr != NULL)
(*sc-sc_lladdr)(sc);
}
-static int
+static void
lagg_capabilities(struct lagg_softc *sc)
{
struct lagg_port *lp;
- int cap = ~0, priv;
+ int cap = ~0, ena = ~0;
LAGG_LOCK_ASSERT(sc);
- /* Preserve private capabilities */
- priv = sc-sc_capabilities IFCAP_LAGG_MASK;
+ if (SLIST_EMPTY(sc-sc_ports))
+ return;
/* Get capabilities from the lagg ports */
- SLIST_FOREACH(lp, sc-sc_ports, lp_entries)
- cap = lp-lp_capabilities;
+ SLIST_FOREACH(lp, sc-sc_ports, lp_entries) {
+ cap = lp-lp_ifp-if_capabilities;
+ ena = lp-lp_ifp-if_capenable;
+ }
+
+ if (sc-sc_ifp-if_capabilities != cap ||
+ sc-sc_ifp-if_capenable != ena) {
+ sc-sc_ifp-if_capabilities = cap;
+ sc-sc_ifp-if_capenable = ena;
+ getmicrotime(sc-sc_ifp-if_lastchange);
- if (sc-sc_ifflags IFF_DEBUG) {
- printf(%s: capabilities 0x%08x\n,
- sc-sc_ifname, cap == ~0 ? priv : (cap | priv));
+ if (sc-sc_ifflags IFF_DEBUG)
+ if_printf(sc-sc_ifp,
+ capabilities 0x%08x enabled 0x%08x\n, cap, ena);
}
+}
+
+static void
+lagg_mtu(struct lagg_softc *sc)
+{
+ struct lagg_port *lp;
+ int mtu = IF_MAXMTU;
+
+ LAGG_LOCK_ASSERT(sc);
+
+ if (SLIST_EMPTY(sc-sc_ports))
+ return;
- return (cap == ~0 ? priv : (cap | priv));
+ /* Get the lowest MTU from the lagg ports */
+ SLIST_FOREACH(lp, sc-sc_ports, lp_entries)
+ if (lp-lp_ifp-if_mtu mtu)
+ mtu = lp-lp_ifp-if_mtu;
+
+ if (sc-sc_ifp-if_mtu != mtu) {
+ sc-sc_ifp-if_mtu = mtu;
+ getmicrotime(sc-sc_ifp-if_lastchange);
+ }
}
static void
@@ -497,8 +527,9 @@ lagg_port_create(struct lagg_softc *sc,
SLIST_INSERT_HEAD(sc-sc_ports, lp, lp_entries);
sc-sc_count++;
- /* Update lagg capabilities */
- sc-sc_capabilities = lagg_capabilities(sc);
+ /* Update lagg capabilities and mtu */
+ lagg_capabilities(sc);
+ lagg_mtu(sc);
/* Add multicast addresses and interface flags to this port */
lagg_ether_cmdmulti(lp, 1);
@@ -602,8 +633,9 @@ lagg_port_destroy(struct lagg_port *lp,
free(lp, M_DEVBUF);
- /* Update lagg capabilities */
- sc-sc_capabilities = lagg_capabilities(sc);
+ /* Update lagg capabilities and mtu */
+ lagg_capabilities(sc);
+ lagg_mtu(sc);
return (0);
}
@@ -638,6 +670,24 @@ lagg_port_ioctl(struct ifnet *ifp, u_lon
lagg_port2req(lp, rp);
LAGG_UNLOCK(sc);
break;
+
+ case SIOCSIFCAP:
+ case
Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks?
Howard Goldstein wrote: Howard Goldstein wrote: Has anyone done any benchmarks in desktop or server environment comparing geom with an ICH controller through the ar device in RAID1 service? Teh google, it seems to pick up grammar school math assignments lots of what may be relevant hits for fortunate speakers of German :( In case it may help someone else I've some benchmarks to share. These are trivial and naive benchmarks since they test only one case which probably is the worst case for geom. Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem mounted with softupdates, remounted after each test P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller detects these SATA-II drives inexplicably as SATA-I ICH5 only support SATA-1. Naive test: dd if=/dev/zero of=/fsundertest/tstfile bs=1m count=1000 *not including buffered stuff unwritten, the test simply reported dd's idea of the transfer time*, and then the other way where it doesn't matter In firmware's RAID1 Using the awesome gmirror write 1gb: 13.275 13.7 rd 12.9 13.8 Of course after this I used gmirror... Just so we're clear, the ICH5 doesn't have any firmware and doesn't actually do any RAID operations. What is has is hook into the system BIOS during boot. That hook allows the BIOS to do RAID-like operations during boot, until the OS takes over control of the devices. After that, it's up to the OS to do all the RAID work. The 'ar' driver is still software RAID, just like gmirror. What you've effectively done merely compare the performance of one software RAID stack to another. That's certainly an interesting comparison, but maybe not exactly what you had in mind. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
Most people didnt see a problem which is why this slipped through. tcpdump on another host with the -e flag and see what the src mac is. All zeros! very interesting - am surprised the switch didn't kick up a fuss about that. Well, patch applied and rebooting... thanks, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
All zeros! very interesting - am surprised the switch didn't kick up a fuss about that. Well, patch applied and rebooting... ...and now all my outgoing packets have the correct MAC address as expected on them. I alos notice that I am now only seeing packets destined for the appropriate machine comming out of my switch. Before the patch I could see all the packets for all machine using tcpdup. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
On Wed, Jul 25, 2007 at 12:54:30PM +0100, Pete French wrote: lagg on RELENG_6 is currently broken due to subtle differences that wernt taken into account when it was MFCd. Can you please test this patch. Erp! Do you have any mor einfo on tyhis - what kinds of things does this break ? Since lagg arrived I have deployed it on all our production machines. It seems to work fine for me, I have to say, but I would like to know what problems I might be about to encounter. Will apply and test your patch (though having seen no problems anyway I am not sure how useful that will be). The MAC address was not set correctly on the lagg interface so all outgoing frames have the src of 00:00:00:00:00:00. This still worked in a lot of situations as the machine replied with the correct arp address and the configured laggports had the correct MAC. Most people didnt see a problem which is why this slipped through. tcpdump on another host with the -e flag and see what the src mac is. Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pmtud + ipnat RELENG_6_2 appears to be broken
patch did not help ... ifconfig: # ifconfig em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (1000baseTX full-duplex) status: active lagg: laggdev lagg0 em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect (1000baseTX full-duplex) status: active lagg: laggdev lagg0 pfsync0: flags=0 mtu 2020 syncpeer: 224.0.0.240 maxupd: 128 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 pflog0: flags=141UP,RUNNING,PROMISC mtu 33160 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.0.0.1 netmask 0x broadcast 10.0.255.255 inet 10.0.0.2 netmask 0x broadcast 10.0.255.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active laggproto lacp laggport: em1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em0 flags=1cACTIVE,COLLECTING,DISTRIBUTING vlan302: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1496 inet 192.168.111.7 netmask 0xff00 broadcast 192.168.111.255 inet 192.168.111.1 netmask 0xff00 broadcast 192.168.111.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active vlan: 302 parent interface: lagg0 vlan150: flags=8843UP,BROADCAST ,RUNNING,SIMPLEX,MULTICAST mtu 1496 inet 192.168.150.1 netmask 0xff00 broadcast 192.168.150.255 ether XX:XX:XX:XX:XX:XX media: Ethernet autoselect status: active vlan: 150 parent interface: lagg0 and other VLANs . all on lagg0 interface i was tried to change laggproto, it doesn't help. i can NOT increase MTU on lagg interface above 1500 and on vlan interface above lagg's MTU -4 . also i've increased MTU on both ems to 9000 and after that i still can't increase MTU on lagg interface above 1500 please, HELP ... and VERY LITTLE part of dmesg: vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) vlan301: discard oversize frame (ether type 800 flags 3 len 1514 max 1510) 2007/7/25, Andrew Thompson [EMAIL PROTECTED] : On Wed, Jul 25, 2007 at 03:15:17AM +0400, Alexey Karagodov wrote: is there any progress? just one me too this problem appeared for me when i try to use vlan over lagg ( to em NICs ) lagg on RELENG_6 is currently broken due to subtle differences that wernt taken into account when it was MFCd. Can you please test this patch. Index: if_lagg.c === RCS file: /home/ncvs/src/sys/net/if_lagg.c,v retrieving revision 1.11.2.3 diff -u -p -r1.11.2.3 if_lagg.c --- if_lagg.c 12 Jul 2007 20:40:24 - 1.11.2.3 +++
[resolved, naively] Re: geom vs ich through ar device - benchmarks?
Howard Goldstein wrote: Has anyone done any benchmarks in desktop or server environment comparing geom with an ICH controller through the ar device in RAID1 service? Teh google, it seems to pick up grammar school math assignments lots of what may be relevant hits for fortunate speakers of German :( In case it may help someone else I've some benchmarks to share. These are trivial and naive benchmarks since they test only one case which probably is the worst case for geom. Testbed: Pair of WDC3200AAKS 320gb SATA, freshly newfsd 10gb filesystem mounted with softupdates, remounted after each test P4 @ 3ghz on a P4P800 in 6.2-STABLE, single user mode, ICH5R controller detects these SATA-II drives inexplicably as SATA-I Naive test: dd if=/dev/zero of=/fsundertest/tstfile bs=1m count=1000 *not including buffered stuff unwritten, the test simply reported dd's idea of the transfer time*, and then the other way where it doesn't matter In firmware's RAID1 Using the awesome gmirror write 1gb: 13.275 13.7 rd 12.9 13.8 Of course after this I used gmirror... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
