> Hi Dale, > The setting is required on the data receive computer side, > and is done by our system administrator in GB. > > Sorry but I do not know how to set that myself. >
Hi Dale, Good catch, Glen! On our Red Hat 5.x systems, in the /etc/sysconfig/network-scripts directory, the following config file sets up the 10 GbE port on our data acquisition machine: Yes, Master<1043> more ifcfg-eth2 DEVICE=eth2 HWADDR=00:60:DD:45:7F:02 ONBOOT=yes TYPE=Ethernet IPADDR=192.168.3.15 MTU=9000 John > Glen > >> Hi Glen, >> >> Thanks for the reply, and the useful example from your system. It looks >> like a configuration problem on the ROACH side, then. Is there a >> configuration file somewhere that tells tgtap about Jumbo packets and so >> on? We are sending 6k packets, so will definitely need it. I do not >> see >> any information on that from tgtap -h, and there is no man page. >> >> Regards, >> Dale >> ________________________________________ >> From: Glen Langston [[email protected]] >> Sent: Thursday, January 05, 2012 11:45 PM >> To: Gary, Dale >> Cc: [email protected] >> Subject: Re: [casper] Problem with tap? >> >> Hi >> >> Your commands seem fine, (but not the mac address). >> >> One note, the 10 GBe is not configured for jumbo packets. >> >> For Jumbo packets you'd expect >> >> MTU:9000 >> >> ie for our 10 GBe link to a bee2 we have: >> >> eth2 Link encap:Ethernet HWaddr 00:60:DD:45:9F:76 >> inet addr:192.168.3.68 Bcast:192.168.3.255 >> Mask:255.255.255.0 >> UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 >> RX packets:1090598864 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:131516 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:8766147319262 (7.9 TiB) TX bytes:14799961 (14.1 MiB) >> Interrupt:90 >> >> Glen >> >>> Hi All, >>> >>> I am setting up a ROACH at the observatory that worked fine in the lab. >>> However, here I am not getting 10Gbe packets, although the internal >>> counters show that the design is creating them. I looked around and >>> believe I have a problem with the tap creation. The Python script does >>> this: >>> >>> print 'Configuring transmitter core...', >>> sys.stdout.flush() >>> >>> fpga.tap_start('tap3',tx_core_name,mac_base+source_ip,source_ip,fabric_port) >>> print 'done' >>> >>> where >>> >>> source_ip=10*(2**24) + 20 #10.0.0.20 >>> mac_base=(2<<40) + (2<<32) >>> >>> I therefore expect a hardware address 00 02 02 10 00 00 20. When I do >>> an >>> ifconfig, I see >>> >>> tap3 Link encap:UNSPEC HWaddr >>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 >>> inet addr:10.0.0.20 P-t-P:10.0.0.20 Mask:255.255.255.0 >>> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:500 >>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) >>> >>> That is a lot of zeros in the hardware address! Am I right that this >>> anomalous hardware MAC address is the cause of the problem? I could >>> have >>> some setup wrong somewhere. Any ideas what could cause this? All >>> other >>> register settings seem to work okay. >>> >>> Thanks, >>> Dale >>> >> >> >> > > >
