Kevin, Glad to hear you are up and running. Daisy chaining (aka stacking) switches is actually perfectly good practice. For you as an SDR user the only potential impact is potentially a latency increase…there’s one or two applications where that might be a factor. Report back if you ever get resolution from Netgear, we’d all like to stay away from known problematic equipment. -Ian > On Nov 29, 2017, at 11:12 AM, Kevin Krieger <kevin.krieger@usask.ca> wrote: > > Hi Ian, > > Just as an update, we've purchased 3 XS708E's. We've daisy chained them and we have all 16 N200 devices plugged in, a 10G intel card in the computer, and the tx_bursts example runs flawlessly on all the devices at once. It's cheaper than buying one XS728T, but it takes up more space and I suspect daisy-chaining 3 switches together isn't best practice... > NETGEAR is currently looking into the issue with why the XS728T doesn't work, so hopefully they figure that out. > > In the meantime, we move on with 3 switches. > > Kevin > > On 11/10/2017 05:52 PM, Ian Buckley wrote: >> Kevin, >> I wouldn’t expend more effort at the moment on the dissector, the UDP ports and packet sizes pretty much tell you whats going on if you understand UHD. It may be that the dissector for the old UHD protocol was never complete/perfect. >> >> Interesting that it was the monitoring port that was 10G and the host 1G….this kind of illustrates my point about using a dedicated non rate converting monitoring switch since the 10G port delivered bursts of packets to Wireshark at intervals that were much too close to have been the original 1G timing. >> >> Maybe your route forward is two XS708E’s if that’s robust…frustrating to not solve the issue but a better use of your time I suspect. >> -Ian >> >> >>> On Nov 10, 2017, at 9:17 AM, Kevin Krieger <kevin.krieger@usask.ca <mailto:kevin.krieger@usask.ca>> wrote: >>> >>> Hi Ian, >>> >>> OK - is there code for the dissector available to build a new version? Or do you think it's worth it? >>> >>> Also - our host sending the samples was actually only 1Gbps ethernet (we weren't using the 10Gbps card for that), so I'm not sure that the samples would be going into the switch faster than this. We were using the 10G card for wireshark. >>> Thanks for the info about the N210 ethernet port, maybe we can try forcing the switch ports to 1G and see if that helps. >>> Also adding a 1G switch in between the USRP and 10G will be a good test if we can get our hands on a 1G switch. >>> We discussed just getting four 4port 1G cards, we would need to upgrade our motherboard though. >>> >>> Thanks, If we figure anything out we'll post back here. >>> >>> Regards, >>> Kevin >>> >>> On 11/09/2017 09:14 AM, Ian Buckley wrote: >>>> >>>> Kevin, >>>> I glanced through Captures 0,1,2 and could see the general gist of where it all goes wrong, but it’s not really clear why. The dissector seems out of date, at least it isn’t decoding correctly but I can still follow it. >>>> >>>> Capture 0: >>>> Packets 2551 through 2606 are the actual sample data packets. >>>> Then there is an approx 1.2second pause before UHD, having timed out waiting for ACK’s begins some basic control interaction initiated by the host. >>>> >>>> Contrast that with Capture 2, where you will see a nicely paced stream of ACK’s (starts at packet 2609) flowing back from the USRP at exact intervals pacing the real time TX operation as the DSP consumes the samples. >>>> >>>> Capture 1: >>>> This goes to the weeds early, streaming never gets close to starting. At around packet 1324 you suddenly see a series of pauses for exactly 0.5 secs each. >>>> >>>> So a couple of thoughts bordering on guesses: >>>> >>>> Rate conversion in switches is always a little bit of a minefield when you have a single stream that is faster than the skinny pipe. In this case, operations like the sample burst are streaming from the host faster than 1Gbs into the switch forcing the switch to buffer samples. It’s surprising sometimes how quick these lower cost single chip switches can get buffer starved. Try using 'ethtool' on the Linux host to force the host port to 1Gbps to eliminate rate conversion in the switch as a cause. >>>> >>>> N210 in general is the most reliable of all USRP’s but it has one quirk, which is that the ethernet port is forced to be 1Gbps and it does no auto negotiation. This often trips up people who connect it to a 100mbit switch or host. I have never actually tried connecting it to 10GBase-T switches…there may be some (switch implementation specific) gotcha’s. >>>> >>>> Mirroring multiple ports to a single port can affect how the problem manifests because you create new bottle necks in the switch …if the 10G switch is suspect then I suggest interposing a cheap 1G switch that supports mirroring between USRP and 10G switch, that way you’ll have higher confidence exactly what and when went onto the wire. This is also an interesting experiment because it isolates the N210’s ethernet port from the 10G switch…curious to see if it now starts to work OK. I have had this happen when debugging other products. >>>> >>>> The ICMP port unreachable is likely a red herring, some spurious Linux service rather than UHD originating those packets I suspect. >>>> >>>> Might be worth looking at the switch internal counters to see if any physical layer error counters are increasing. >>>> >>>> No smoking gun I’m afraid; your fall back plan might be to stuff quad port 1G cards in your host, they’re cheap if you have the PCIe slots free. >>>> >>>> -Ian >>>> >>>>> On Nov 6, 2017, at 3:13 PM, Kevin Krieger via USRP-users <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Any chance to look at these wireshark captures? >>>>> >>>>> Thanks, >>>>> Kevin >>>>> >>>>> On 10/30/2017 05:30 PM, Kevin Krieger via USRP-users wrote: >>>>>> Hi Marcus, >>>>>> >>>>>> I finally got around to this. >>>>>> I've attached 9 captures. >>>>>> >>>>>> The setup for the captures was: >>>>>> XS728T with latest firmware running, factory default >>>>>> Computer running tx_bursts has IP of 192.168.10.60 or .67 >>>>>> N200 has IP of 192.168.10.107 >>>>>> ./tx_bursts --args addr0=192.168.10.107 --freq 10e6 --rate 1e6 >>>>>> >>>>>> Captures 0,1 and 2 are with both the ports (n200 side, and computer side) mirrored to the wireshark capture port, so you essentially see duplicate traffic. >>>>>> Captures 3,4 and 5 are with only the computer side traffic captured >>>>>> Captures 6,7 and 8 are with only the N200 side traffic captured. >>>>>> >>>>>> Captures 0, 4, and 8 are with the messages "Sent packet: 363 samples" appearing, but then the "Waiting for async burst ACK ... fail" message also appears. >>>>>> Captures 1, 3 and 7 are with the message :Error: Runtimeerror: fifo ctrl timed out looking for acks" appearing. >>>>>> Captures 2, 5 and 6 are with successful runs of the tx bursts program, so instead of 'fail' at the end there is 'success'. >>>>>> >>>>>> There are txt files with the output of the program for each capture, as well as csv files showing the dissected output (only found uhd in the dissectors). >>>>>> >>>>>> Can you see anything wrong with these runs? Any help is appreciated. >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> >>>>>> >>>>>> On 06/15/2017 02:28 PM, Kevin Krieger via USRP-users wrote: >>>>>>> Hi Marcus, >>>>>>> >>>>>>> Thank you - I was sure that the same subnet was correct but it's good to have confirmation. >>>>>>> I have done the dissecting previously, and I recall getting a bunch of "huh what's that?"' messages and then a 'wassup bro' or something but I'll do it again and let you know what I see. (Hilarious descriptions btw!) >>>>>>> >>>>>>> Kevin >>>>>>> >>>>>>> >>>>>>> On 05/24/2017 08:07 PM, Marcus Müller via USRP-users wrote: >>>>>>>> Hi Kevin, Hi Robin, >>>>>>>> the same-subnet configuration is the right one, here. There's no routing ambiguity if you have one card that serves the whole switch. >>>>>>>> Kevin, this might be much to ask, but: I'd ask you to both install wireshark and its development headers (typically, wireshark-dev or wireshark-devel) from your operating system's package manager. >>>>>>>> Then, get the UHD source code, and >>>>>>>> >>>>>>>> cd /path/to/uhd/tools/dissectors >>>>>>>> mkdir build >>>>>>>> cd build >>>>>>>> cmake -DETTUS_DISSECTOR_NAME=zpu .. >>>>>>>> make -j4 && make install >>>>>>>> >>>>>>>> Ideally, add your user to the group that has access to the raw network hardware (in case of my OS, that was the "wireshark" group), log out and back in. >>>>>>>> >>>>>>>> If that doesn't work, you have to record as root and analyze as your user (the USRP protocol dissectors got installed to your home directory). >>>>>>>> >>>>>>>> Then, record the traffic on your 10G interface, and analyze the packets in question as UHD (some/many will be sample packets, i.e. CVITA). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Marcus >>>>>>>> On 24.05.2017 20:15, ROBIN TORTORA via USRP-users wrote: >>>>>>>>> The only thing that jumps out to me is they are all on the same subnet... >>>>>>>>> >>>>>>>>> >>>>>>>>> That is something I have typically avoided, but if you say it works in another configuration, that may not be the issue... >>>>>>>>> >>>>>>>>>> On May 24, 2017 at 12:12 PM Kevin Krieger via USRP-users <usrp-users@lists.ettus.com> <mailto:usrp-users@lists.ettus.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I've got a predicament. Here's some background before I describe my problem: >>>>>>>>>> We purchased a Netgear xs728T 10GB switch in order to network 16 N200 devices, as well as a processing computer (which has a 10G ethernet card). Our 16 N200 devices are going to be used in a radar configuration where they are all simultaneously either transmitting or receiving. They are all receiving coincident 10MHz and 1PPS signals from 2 octoclocks, which are both fed from a third clock to ensure coincident clocks. They are connected to the switch via cat6 cables ~7feet in length (this item: https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136 <https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136>) >>>>>>>>>> >>>>>>>>>> The problem: >>>>>>>>>> During testing we've found that the example program tx_bursts, when run on one USRP at a time with a modest bandwidth, the "Waiting for async burst ack....failed" message appears about 75% of the time. If I try to use two or more USRPs at a time, then it appears every time. >>>>>>>>>> The line used for tx_bursts was typically something like this: ./tx_bursts --args="addr0=192.168.10.104" --freq 10e6 --rate=1e6 --channels="0" >>>>>>>>>> for a one usrp test. For a multiple usrp test, I used lines like this: ./tx_bursts --args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114" --freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Some evidence & information: >>>>>>>>>> We also have a 5 port 1G DLink DGS-1005G. We've tested 4 N200s with tx_bursts on this switch (same cabling) and it works flawlessly. >>>>>>>>>> We also have tested a second 10G switch, the 8 port XS708E with 7 N200s with tx_bursts and it works flawlessly. >>>>>>>>>> >>>>>>>>>> I have wireshark dumps taken via a third machine that is connected to mirrored ports on the xs728T switch. I have attached them in case anyone can tell me if they see something wrong besides the missing acks. >>>>>>>>>> The wireshark filter to use is : ip.src == 192.168.10.104 and ip.dst == 192.168.10.104 or ip.src == 192.168.10.104 and ip.dst == 192.168.10.99 >>>>>>>>>> >>>>>>>>>> The xs728t switch information is: Boot version is 1.0.0.0, SW version is 6.5.1.26 (latest as of testing). >>>>>>>>>> I contacted Netgear support, and they sent us a brand new switch, which exhibited the same problem. >>>>>>>>>> >>>>>>>>>> I'm wondering if there's anyone out there who has had similar issues? Is there anything I can do to get more information or get around this problem? >>>>>>>>>> Can anyone see what the root cause might be in the wireshark captures? >>>>>>>>>> >>>>>>>>>> Any help or pointers are appreciated. Thank you, >>>>>>>>>> Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>>> >>>>> _______________________________________________ >>>>> USRP-users mailing list >>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >>>> >>> >> >

Hey Ian, Ah that's good to hear, different from my intuition though. I'll keep the list updated on the XS728T. Last I heard, they asked for the network topology, switch logs, program I was running, wireshark captures, and if there were any dhcp or similar servers running on the network. Regards, Kevin On 11/29/2017 10:02 PM, Ian Buckley wrote: > Kevin, > Glad to hear you are up and running. Daisy chaining (aka stacking) > switches is actually perfectly good practice. For you as an SDR user > the only potential impact is potentially a latency increase…there’s > one or two applications where that might be a factor. Report back if > you ever get resolution from Netgear, we’d all like to stay away from > known problematic equipment. > -Ian > >> On Nov 29, 2017, at 11:12 AM, Kevin Krieger <kevin.krieger@usask.ca >> <mailto:kevin.krieger@usask.ca>> wrote: >> >> Hi Ian, >> >> Just as an update, we've purchased 3 XS708E's. We've daisy chained >> them and we have all 16 N200 devices plugged in, a 10G intel card in >> the computer, and the tx_bursts example runs flawlessly on all the >> devices at once. It's cheaper than buying one XS728T, but it takes up >> more space and I suspect daisy-chaining 3 switches together isn't >> best practice... >> NETGEAR is currently looking into the issue with why the XS728T >> doesn't work, so hopefully they figure that out. >> >> In the meantime, we move on with 3 switches. >> >> Kevin >> >> On 11/10/2017 05:52 PM, Ian Buckley wrote: >>> Kevin, >>> I wouldn’t expend more effort at the moment on the dissector, the >>> UDP ports and packet sizes pretty much tell you whats going on if >>> you understand UHD. It may be that the dissector for the old UHD >>> protocol was never complete/perfect. >>> >>> Interesting that it was the monitoring port that was 10G and the >>> host 1G….this kind of illustrates my point about using a dedicated >>> non rate converting monitoring switch since the 10G port delivered >>> bursts of packets to Wireshark at intervals that were much too close >>> to have been the original 1G timing. >>> >>> Maybe your route forward is two XS708E’s if that’s >>> robust…frustrating to not solve the issue but a better use of your >>> time I suspect. >>> -Ian >>> >>> >>>> On Nov 10, 2017, at 9:17 AM, Kevin Krieger <kevin.krieger@usask.ca >>>> <mailto:kevin.krieger@usask.ca>> wrote: >>>> >>>> Hi Ian, >>>> >>>> OK - is there code for the dissector available to build a new >>>> version? Or do you think it's worth it? >>>> >>>> Also - our host sending the samples was actually only 1Gbps >>>> ethernet (we weren't using the 10Gbps card for that), so I'm not >>>> sure that the samples would be going into the switch faster than >>>> this. We were using the 10G card for wireshark. >>>> Thanks for the info about the N210 ethernet port, maybe we can try >>>> forcing the switch ports to 1G and see if that helps. >>>> Also adding a 1G switch in between the USRP and 10G will be a good >>>> test if we can get our hands on a 1G switch. >>>> We discussed just getting four 4port 1G cards, we would need to >>>> upgrade our motherboard though. >>>> >>>> Thanks, If we figure anything out we'll post back here. >>>> >>>> Regards, >>>> Kevin >>>> >>>> On 11/09/2017 09:14 AM, Ian Buckley wrote: >>>>> >>>>> Kevin, >>>>> I glanced through Captures 0,1,2 and could see the general gist of >>>>> where it all goes wrong, but it’s not really clear why. The >>>>> dissector seems out of date, at least it isn’t decoding correctly >>>>> but I can still follow it. >>>>> >>>>> Capture 0: >>>>> Packets 2551 through 2606 are the actual sample data packets. >>>>> Then there is an approx 1.2second pause before UHD, having timed >>>>> out waiting for ACK’s begins some basic control interaction >>>>> initiated by the host. >>>>> >>>>> Contrast that with Capture 2, where you will see a nicely paced >>>>> stream of ACK’s (starts at packet 2609) flowing back from the USRP >>>>> at exact intervals pacing the real time TX operation as the DSP >>>>> consumes the samples. >>>>> >>>>> Capture 1: >>>>> This goes to the weeds early, streaming never gets close to >>>>> starting. At around packet 1324 you suddenly see a series of >>>>> pauses for exactly 0.5 secs each. >>>>> >>>>> So a couple of thoughts bordering on guesses: >>>>> Rate conversion in switches is always a little bit of a minefield >>>>> when you have a single stream that is faster than the skinny pipe. >>>>> In this case, operations like the sample burst are streaming from >>>>> the host faster than 1Gbs into the switch forcing the switch to >>>>> buffer samples. It’s surprising sometimes how quick these lower >>>>> cost single chip switches can get buffer starved. Try using >>>>> 'ethtool' on the Linux host to force the host port to 1Gbps to >>>>> eliminate rate conversion in the switch as a cause. >>>>> >>>>> N210 in general is the most reliable of all USRP’s but it has one >>>>> quirk, which is that the ethernet port is forced to be 1Gbps and >>>>> it does no auto negotiation. This often trips up people who >>>>> connect it to a 100mbit switch or host. I have never actually >>>>> tried connecting it to 10GBase-T switches…there may be some >>>>> (switch implementation specific) gotcha’s. >>>>> >>>>> Mirroring multiple ports to a single port can affect how the >>>>> problem manifests because you create new bottle necks in the >>>>> switch …if the 10G switch is suspect then I suggest interposing a >>>>> cheap 1G switch that supports mirroring between USRP and 10G >>>>> switch, that way you’ll have higher confidence exactly what and >>>>> when went onto the wire. This is also an interesting experiment >>>>> because it isolates the N210’s ethernet port from the 10G >>>>> switch…curious to see if it now starts to work OK. I have had this >>>>> happen when debugging other products. >>>>> >>>>> The ICMP port unreachable is likely a red herring, some spurious >>>>> Linux service rather than UHD originating those packets I suspect. >>>>> >>>>> Might be worth looking at the switch internal counters to see if >>>>> any physical layer error counters are increasing. >>>>> >>>>> No smoking gun I’m afraid; your fall back plan might be to stuff >>>>> quad port 1G cards in your host, they’re cheap if you have the >>>>> PCIe slots free. >>>>> >>>>> -Ian >>>>> >>>>>> On Nov 6, 2017, at 3:13 PM, Kevin Krieger via USRP-users >>>>>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Any chance to look at these wireshark captures? >>>>>> >>>>>> Thanks, >>>>>> Kevin >>>>>> >>>>>> On 10/30/2017 05:30 PM, Kevin Krieger via USRP-users wrote: >>>>>>> Hi Marcus, >>>>>>> >>>>>>> I finally got around to this. >>>>>>> I've attached 9 captures. >>>>>>> >>>>>>> The setup for the captures was: >>>>>>> XS728T with latest firmware running, factory default >>>>>>> Computer running tx_bursts has IP of 192.168.10.60 or .67 >>>>>>> N200 has IP of 192.168.10.107 >>>>>>>  ./tx_bursts  --args addr0=192.168.10.107  --freq 10e6 --rate 1e6 >>>>>>> >>>>>>> Captures 0,1 and 2 are with both the ports (n200 side, and >>>>>>> computer side) mirrored to the wireshark capture port, so you >>>>>>> essentially see duplicate traffic. >>>>>>> Captures 3,4 and 5 are with only the computer side traffic captured >>>>>>> Captures 6,7 and 8 are with only the N200 side traffic captured. >>>>>>> >>>>>>> Captures 0, 4, and 8 are with the messages "Sent packet: 363 >>>>>>> samples" appearing, but then the "Waiting for async burst ACK >>>>>>> ... fail" message also appears. >>>>>>> Captures 1, 3 and 7 are with the message :Error: Runtimeerror: >>>>>>> fifo ctrl timed out looking for acks" appearing. >>>>>>> Captures 2, 5 and 6 are with successful runs of the tx bursts >>>>>>> program, so instead of 'fail' at the end there is 'success'. >>>>>>> >>>>>>> There are txt files with the output of the program for each >>>>>>> capture, as well as csv files showing the dissected output (only >>>>>>> found uhd in the dissectors). >>>>>>> >>>>>>> Can you see anything wrong with these runs? Any help is appreciated. >>>>>>> >>>>>>> Thanks, >>>>>>> Kevin >>>>>>> >>>>>>> >>>>>>> On 06/15/2017 02:28 PM, Kevin Krieger via USRP-users wrote: >>>>>>>> Hi Marcus, >>>>>>>> >>>>>>>> Thank you - I was sure that the same subnet was correct but >>>>>>>> it's good to have confirmation. >>>>>>>> I have done the dissecting previously, and I recall getting a >>>>>>>> bunch of "huh what's that?"' messages and then a 'wassup bro' >>>>>>>> or something but I'll do it again and let you know what I see. >>>>>>>> (Hilarious descriptions btw!) >>>>>>>> >>>>>>>> Kevin >>>>>>>> >>>>>>>> >>>>>>>> On 05/24/2017 08:07 PM, Marcus Müller via USRP-users wrote: >>>>>>>>> >>>>>>>>> Hi Kevin, Hi Robin, >>>>>>>>> >>>>>>>>> the same-subnet configuration is the right one, here. There's >>>>>>>>> no routing ambiguity if you have one card that serves the >>>>>>>>> whole switch. >>>>>>>>> >>>>>>>>> Kevin, this might be much to ask, but: I'd ask you to both >>>>>>>>> install wireshark and its development headers (typically, >>>>>>>>> wireshark-dev or wireshark-devel) from your operating system's >>>>>>>>> package manager. >>>>>>>>> >>>>>>>>> Then, get the UHD source code, and >>>>>>>>> >>>>>>>>> cd /path/to/uhd/tools/dissectors >>>>>>>>> mkdir build >>>>>>>>> cd build >>>>>>>>> cmake -DETTUS_DISSECTOR_NAME=zpu .. >>>>>>>>> make -j4 && make install >>>>>>>>> >>>>>>>>> Ideally, add your user to the group that has access to the raw >>>>>>>>> network hardware (in case of my OS, that was the "wireshark" >>>>>>>>> group), log out and back in. >>>>>>>>> >>>>>>>>> If that doesn't work, you have to record as root and analyze >>>>>>>>> as your user (the USRP protocol dissectors got installed to >>>>>>>>> your home directory). >>>>>>>>> >>>>>>>>> Then, record the traffic on your 10G interface, and analyze >>>>>>>>> the packets in question as UHD (some/many will be sample >>>>>>>>> packets, i.e. CVITA). >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>> On 24.05.2017 20:15, ROBIN TORTORA via USRP-users wrote: >>>>>>>>>> >>>>>>>>>> The only thing that jumps out to me is they are all on the >>>>>>>>>> same subnet... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is something I have typically avoided, but if you say it >>>>>>>>>> works in another configuration, that may not be the issue... >>>>>>>>>> >>>>>>>>>>> On May 24, 2017 at 12:12 PM Kevin Krieger via USRP-users >>>>>>>>>>> <usrp-users@lists.ettus.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I've got a predicament. Here's some *background* before I >>>>>>>>>>> describe my problem: >>>>>>>>>>> We purchased a Netgear xs728T 10GB switch in order to >>>>>>>>>>> network 16 N200 devices, as well as a processing computer >>>>>>>>>>> (which has a 10G ethernet card). Our 16 N200 devices are >>>>>>>>>>> going to be used in a radar configuration where they are all >>>>>>>>>>> simultaneously either transmitting or receiving. They are >>>>>>>>>>> all receiving coincident 10MHz and 1PPS signals from 2 >>>>>>>>>>> octoclocks, which are both fed from a third clock to ensure >>>>>>>>>>> coincident clocks. They are connected to the switch via cat6 >>>>>>>>>>> cables ~7feet in length (this item: >>>>>>>>>>> https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136) >>>>>>>>>>> >>>>>>>>>>> *The problem:* >>>>>>>>>>> During testing we've found that the example program >>>>>>>>>>> tx_bursts, when run on one USRP at a time with a modest >>>>>>>>>>> bandwidth, the "Waiting for async burst ack....failed" >>>>>>>>>>> message appears about 75% of the time. If I try to use two >>>>>>>>>>> or more USRPs at a time, then it appears every time. >>>>>>>>>>> The line used for tx_bursts was typically something like >>>>>>>>>>> this:./tx_bursts --args="addr0=192.168.10.104" --freq 10e6 >>>>>>>>>>> --rate=1e6 --channels="0" >>>>>>>>>>> for a one usrp test. For a multiple usrp test, I used lines >>>>>>>>>>> like this:./tx_bursts >>>>>>>>>>> --args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114" >>>>>>>>>>> --freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Some evidence & information: >>>>>>>>>>> *We also have a 5 port 1G DLink DGS-1005G. We've tested 4 >>>>>>>>>>> N200s with tx_bursts on this switch (same cabling) and it >>>>>>>>>>> works flawlessly. >>>>>>>>>>> We also have tested a second 10G switch, the 8 port XS708E >>>>>>>>>>> with 7 N200s with tx_bursts and it works flawlessly. >>>>>>>>>>> >>>>>>>>>>> I have wireshark dumps taken via a third machine that is >>>>>>>>>>> connected to mirrored ports on the xs728T switch. I have >>>>>>>>>>> attached them in case anyone can tell me if they see >>>>>>>>>>> something wrong besides the missing acks. >>>>>>>>>>> The wireshark filter to use is : ip.src == 192.168.10.104 >>>>>>>>>>> and ip.dst == 192.168.10.104 or ip.src == 192.168.10.104 and >>>>>>>>>>> ip.dst == 192.168.10.99 >>>>>>>>>>> >>>>>>>>>>> The xs728t switch information is: Boot version is 1.0.0.0, >>>>>>>>>>> SW version is 6.5.1.26 (latest as of testing). >>>>>>>>>>> I contacted Netgear support, and they sent us a brand new >>>>>>>>>>> switch, which exhibited the same problem. >>>>>>>>>>> >>>>>>>>>>> I'm wondering if there's anyone out there who has had >>>>>>>>>>> similar issues? Is there anything I can do to get more >>>>>>>>>>> information or get around this problem? >>>>>>>>>>> Can anyone see what the root cause might be in the wireshark >>>>>>>>>>> captures? >>>>>>>>>>> >>>>>>>>>>> Any help or pointers are appreciated. Thank you, >>>>>>>>>>> Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> USRP-users mailing list >>>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> USRP-users mailing list >>>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list >>>>>>>>> USRP-users@lists.ettus.com >>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> USRP-users mailing list >>>>>>>> USRP-users@lists.ettus.com >>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list >>>>>>> USRP-users@lists.ettus.com >>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list >>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>>> >>>> >>> >> >