Hello! Has anybody experienced network latency problems with combination of Windows 7, GPLPV drivers and RDP connection? Any Windows pop-up message(such as "command not found" error message in "Run command:" dialog, or dividing by zero in windows calc) causes a short freeze of RDP session and looks like that from dom0: PING 192.168.44.65 (192.168.44.65) 56(84) bytes of data. 64 bytes from 192.168.44.65: icmp_seq=1 ttl=128 time=0.649 ms 64 bytes from 192.168.44.65: icmp_seq=2 ttl=128 time=0.232 ms 64 bytes from 192.168.44.65: icmp_seq=3 ttl=128 time=0.273 ms 64 bytes from 192.168.44.65: icmp_seq=4 ttl=128 time=501 ms 64 bytes from 192.168.44.65: icmp_seq=5 ttl=128 time=0.205 ms 64 bytes from 192.168.44.65: icmp_seq=6 ttl=128 time=0.463 ms 64 bytes from 192.168.44.65: icmp_seq=7 ttl=128 time=0.206 ms where 192.168.44.65 is domU address. The latency may vary from 500 to 10000 ms. The very same actions taken via VNC connection to VM work fine without any problem. We have tried different Windows 7 distros, 32- and 64-bit editions, Windows and Linux RDP clients, with the same result. Software used: Xen version 4.1.2_05-1.1.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Sun Oct 30 03:25:04 UTC 2011 gplpv_Vista2008x32_signed_0.11.0.308 Windows 7 SP1 timer_mode is set to 1, offload settings are: Offload parameters for vif2.0: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off ntuple-filters: off receive-hashing: off Thanks in advance!
> > Hello! > > Has anybody experienced network latency problems with combination of > Windows 7, GPLPV drivers and RDP connection? > Any Windows pop-up message(such as "command not found" error message > in "Run command:" dialog, or dividing by zero in windows calc) causes a short > freeze of RDP session and looks like that from dom0: > > PING 192.168.44.65 (192.168.44.65) 56(84) bytes of data. > 64 bytes from 192.168.44.65: icmp_seq=1 ttl=128 time=0.649 ms > 64 bytes from 192.168.44.65: icmp_seq=2 ttl=128 time=0.232 ms > 64 bytes from 192.168.44.65: icmp_seq=3 ttl=128 time=0.273 ms > 64 bytes from 192.168.44.65: icmp_seq=4 ttl=128 time=501 ms > 64 bytes from 192.168.44.65: icmp_seq=5 ttl=128 time=0.205 ms > 64 bytes from 192.168.44.65: icmp_seq=6 ttl=128 time=0.463 ms > 64 bytes from 192.168.44.65: icmp_seq=7 ttl=128 time=0.206 ms > > where 192.168.44.65 is domU address. The latency may vary from 500 to > 10000 ms. > > The very same actions taken via VNC connection to VM work fine without > any problem. > We have tried different Windows 7 distros, 32- and 64-bit editions, Windows > and Linux RDP clients, with the same result. > > Software used: > Xen version 4.1.2_05-1.1.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Sun Oct > 30 03:25:04 UTC 2011 > gplpv_Vista2008x32_signed_0.11.0.308 > Windows 7 SP1 > > timer_mode is set to 1, offload settings are: > Offload parameters for vif2.0: > rx-checksumming: off > tx-checksumming: off > scatter-gather: off > tcp-segmentation-offload: off > udp-fragmentation-offload: off > generic-segmentation-offload: off > generic-receive-offload: off > large-receive-offload: off > rx-vlan-offload: off > tx-vlan-offload: off > ntuple-filters: off > receive-hashing: off > > Thanks in advance! >I can''t reproduce this. My RDP connections continue uninterrupted. Does it behave the same without the PV drivers installed? James
Hello!> My RDP connections continue uninterrupted.So do mine. It just freezes for a second when a pop-up window appears.> Does it behave the same without the PV drivers installed?No. The only two ways to workaround this problem are either to boot with "NOGPLPV" or to use VNC. Also I've migrated the VM to older kernel(2.6.31.12-0.1-xen) with no success. Here's the vm config, maybe I missed something: name = 'win-seven' memory = '768' bootloader = "hvmloader" disk = [ 'file:/data/win-seven.img,hda,w', ] vif = [ 'mac=10:78:c0:a8:69:69', # 'model=e1000', ] vfb = ['type=vnc,vnclisten=0.0.0.0,vncdisplay=491'] builder='hvm' acpi=1 apic=1 boot='dc' usbdevice='tablet' timer_mode=1 09.02.2012, 02:10, "James Harper" <james.harper@bendigoit.com.au>:>> Hello! >> >> Has anybody experienced network latency problems with combination of >> Windows 7, GPLPV drivers and RDP connection? >> Any Windows pop-up message(such as "command not found" error message >> in "Run command:" dialog, or dividing by zero in windows calc) causes a short >> freeze of RDP session and looks like that from dom0: >> >> PING 192.168.44.65 (192.168.44.65) 56(84) bytes of data. >> 64 bytes from 192.168.44.65: icmp_seq=1 ttl=128 time=0.649 ms >> 64 bytes from 192.168.44.65: icmp_seq=2 ttl=128 time=0.232 ms >> 64 bytes from 192.168.44.65: icmp_seq=3 ttl=128 time=0.273 ms >> 64 bytes from 192.168.44.65: icmp_seq=4 ttl=128 time=501 ms >> 64 bytes from 192.168.44.65: icmp_seq=5 ttl=128 time=0.205 ms >> 64 bytes from 192.168.44.65: icmp_seq=6 ttl=128 time=0.463 ms >> 64 bytes from 192.168.44.65: icmp_seq=7 ttl=128 time=0.206 ms >> >> where 192.168.44.65 is domU address. The latency may vary from 500 to >> 10000 ms. >> >> The very same actions taken via VNC connection to VM work fine without >> any problem. >> We have tried different Windows 7 distros, 32- and 64-bit editions, Windows >> and Linux RDP clients, with the same result. >> >> Software used: >> Xen version 4.1.2_05-1.1.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Sun Oct >> 30 03:25:04 UTC 2011 >> gplpv_Vista2008x32_signed_0.11.0.308 >> Windows 7 SP1 >> >> timer_mode is set to 1, offload settings are: >> Offload parameters for vif2.0: >> rx-checksumming: off >> tx-checksumming: off >> scatter-gather: off >> tcp-segmentation-offload: off >> udp-fragmentation-offload: off >> generic-segmentation-offload: off >> generic-receive-offload: off >> large-receive-offload: off >> rx-vlan-offload: off >> tx-vlan-offload: off >> ntuple-filters: off >> receive-hashing: off >> >> Thanks in advance! > > I can't reproduce this. My RDP connections continue uninterrupted. > > Does it behave the same without the PV drivers installed? > > James > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
So, you are running a Windows 7 system with less than a gig of RAM? You might start there...bump it to 2 gigs and see if that helps. 2012/2/13 Kreved <krevedinho@yandex.ru>:> Hello! > >> My RDP connections continue uninterrupted. > > So do mine. It just freezes for a second when a pop-up window appears. > >> Does it behave the same without the PV drivers installed? > > No. The only two ways to workaround this problem are either to boot with "NOGPLPV" or to use VNC. > > Also I've migrated the VM to older kernel(2.6.31.12-0.1-xen) with no success. > > Here's the vm config, maybe I missed something: > > name = 'win-seven' > memory = '768' > bootloader = "hvmloader" > disk = [ > 'file:/data/win-seven.img,hda,w', > ] > vif = [ > 'mac=10:78:c0:a8:69:69', > # 'model=e1000', > ] > vfb = ['type=vnc,vnclisten=0.0.0.0,vncdisplay=491'] > builder='hvm' > acpi=1 > apic=1 > boot='dc' > usbdevice='tablet' > timer_mode=1 > > 09.02.2012, 02:10, "James Harper" <james.harper@bendigoit.com.au>: >>> Hello! >>> >>> Has anybody experienced network latency problems with combination of >>> Windows 7, GPLPV drivers and RDP connection? >>> Any Windows pop-up message(such as "command not found" error message >>> in "Run command:" dialog, or dividing by zero in windows calc) causes a short >>> freeze of RDP session and looks like that from dom0: >>> >>> PING 192.168.44.65 (192.168.44.65) 56(84) bytes of data. >>> 64 bytes from 192.168.44.65: icmp_seq=1 ttl=128 time=0.649 ms >>> 64 bytes from 192.168.44.65: icmp_seq=2 ttl=128 time=0.232 ms >>> 64 bytes from 192.168.44.65: icmp_seq=3 ttl=128 time=0.273 ms >>> 64 bytes from 192.168.44.65: icmp_seq=4 ttl=128 time=501 ms >>> 64 bytes from 192.168.44.65: icmp_seq=5 ttl=128 time=0.205 ms >>> 64 bytes from 192.168.44.65: icmp_seq=6 ttl=128 time=0.463 ms >>> 64 bytes from 192.168.44.65: icmp_seq=7 ttl=128 time=0.206 ms >>> >>> where 192.168.44.65 is domU address. The latency may vary from 500 to >>> 10000 ms. >>> >>> The very same actions taken via VNC connection to VM work fine without >>> any problem. >>> We have tried different Windows 7 distros, 32- and 64-bit editions, Windows >>> and Linux RDP clients, with the same result. >>> >>> Software used: >>> Xen version 4.1.2_05-1.1.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Sun Oct >>> 30 03:25:04 UTC 2011 >>> gplpv_Vista2008x32_signed_0.11.0.308 >>> Windows 7 SP1 >>> >>> timer_mode is set to 1, offload settings are: >>> Offload parameters for vif2.0: >>> rx-checksumming: off >>> tx-checksumming: off >>> scatter-gather: off >>> tcp-segmentation-offload: off >>> udp-fragmentation-offload: off >>> generic-segmentation-offload: off >>> generic-receive-offload: off >>> large-receive-offload: off >>> rx-vlan-offload: off >>> tx-vlan-offload: off >>> ntuple-filters: off >>> receive-hashing: off >>> >>> Thanks in advance! >> >> I can't reproduce this. My RDP connections continue uninterrupted. >> >> Does it behave the same without the PV drivers installed? >> >> James >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> So, you are running a Windows 7 system with less than a gig of RAM? > You might start there...bump it to 2 gigs and see if that helps.The initial configuration was 6 gigs, so I think it is not the case. 13.02.2012, 17:32, "Scott Damron" <sdamron@gmail.com>:> So, you are running a Windows 7 system with less than a gig of RAM? > You might start there...bump it to 2 gigs and see if that helps. > > 2012/2/13 Kreved <krevedinho@yandex.ru>: > >> Hello! >>> My RDP connections continue uninterrupted. >> So do mine. It just freezes for a second when a pop-up window appears. >>> Does it behave the same without the PV drivers installed? >> No. The only two ways to workaround this problem are either to boot with "NOGPLPV" or to use VNC. >> >> Also I've migrated the VM to older kernel(2.6.31.12-0.1-xen) with no success. >> >> Here's the vm config, maybe I missed something: >> >> name = 'win-seven' >> memory = '768' >> bootloader = "hvmloader" >> disk = [ >> 'file:/data/win-seven.img,hda,w', >> ] >> vif = [ >> 'mac=10:78:c0:a8:69:69', >> # 'model=e1000', >> ] >> vfb = ['type=vnc,vnclisten=0.0.0.0,vncdisplay=491'] >> builder='hvm' >> acpi=1 >> apic=1 >> boot='dc' >> usbdevice='tablet' >> timer_mode=1 >> >> 09.02.2012, 02:10, "James Harper" <james.harper@bendigoit.com.au>: >>>> Hello! >>>> >>>> Has anybody experienced network latency problems with combination of >>>> Windows 7, GPLPV drivers and RDP connection? >>>> Any Windows pop-up message(such as "command not found" error message >>>> in "Run command:" dialog, or dividing by zero in windows calc) causes a short >>>> freeze of RDP session and looks like that from dom0: >>>> >>>> PING 192.168.44.65 (192.168.44.65) 56(84) bytes of data. >>>> 64 bytes from 192.168.44.65: icmp_seq=1 ttl=128 time=0.649 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=2 ttl=128 time=0.232 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=3 ttl=128 time=0.273 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=4 ttl=128 time=501 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=5 ttl=128 time=0.205 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=6 ttl=128 time=0.463 ms >>>> 64 bytes from 192.168.44.65: icmp_seq=7 ttl=128 time=0.206 ms >>>> >>>> where 192.168.44.65 is domU address. The latency may vary from 500 to >>>> 10000 ms. >>>> >>>> The very same actions taken via VNC connection to VM work fine without >>>> any problem. >>>> We have tried different Windows 7 distros, 32- and 64-bit editions, Windows >>>> and Linux RDP clients, with the same result. >>>> >>>> Software used: >>>> Xen version 4.1.2_05-1.1.1 (abuild@) (gcc version 4.6.2 (SUSE Linux) ) Sun Oct >>>> 30 03:25:04 UTC 2011 >>>> gplpv_Vista2008x32_signed_0.11.0.308 >>>> Windows 7 SP1 >>>> >>>> timer_mode is set to 1, offload settings are: >>>> Offload parameters for vif2.0: >>>> rx-checksumming: off >>>> tx-checksumming: off >>>> scatter-gather: off >>>> tcp-segmentation-offload: off >>>> udp-fragmentation-offload: off >>>> generic-segmentation-offload: off >>>> generic-receive-offload: off >>>> large-receive-offload: off >>>> rx-vlan-offload: off >>>> tx-vlan-offload: off >>>> ntuple-filters: off >>>> receive-hashing: off >>>> >>>> Thanks in advance! >>> I can't reproduce this. My RDP connections continue uninterrupted. >>> >>> Does it behave the same without the PV drivers installed? >>> >>> James >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> > So, you are running a Windows 7 system with less than a gig of RAM? > You might start there...bump it to 2 gigs and see if that helps. >That''s probably a good start. If that doesn''t help things along then we''ll need to start taking packet traces and see if there is a corruption problem somewhere although it doesn''t make sense that it would just happen in the cases you are describing. James
Traces taken on host and guest systems have shown that the guest stops to
receive packets for a period of time, and then gets them all at once. This
period of silence depends on rdp-client used: rdesktop-vrdp and mstsc continue
to work after a second, rdesktop hangs for one minute and exits on timeout. The
host system vif interface sees all incoming and outgoing packets including
guest's retransmit attempts.
Dumping Xen Net Device during rdesktop's one minute freeze shows that guest
system(192.168.44.141) becomes blind until rdesktop window closes:
513 4.164811 192.168.44.141 192.168.100.99 TPKT 1514
Continuation
514 4.164815 192.168.44.141 192.168.100.99 TPKT 1514
Continuation
515 4.164818 192.168.44.141 192.168.100.99 TPKT 1064
Continuation
516 4.416053 192.168.44.141 192.168.100.99 TPKT 1514
[TCP Retransmission] Continuation
517 5.017615 192.168.44.141 192.168.100.99 TPKT 1514
[TCP Retransmission] Continuation
518 6.218786 192.168.44.141 192.168.100.99 TPKT 1514
[TCP Retransmission] Continuation
519 8.619176 192.168.44.141 192.168.100.99 TPKT 1514
[TCP Retransmission] Continuation
520 9.856471 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
521 10.856480 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
522 11.856470 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
523 13.420006 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
524 14.356480 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
525 15.356472 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
526 23.022567 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
527 23.857451 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
528 24.857453 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
529 42.223754 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
530 42.857480 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
531 43.857469 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
532 64.167428 Xensourc_19:20:fe Broadcast ARP 42
Who has 192.168.100.99? Tell 192.168.44.141
533 64.225180 192.168.100.99 192.168.44.141 TCP 66
33180 > ms-wbt-server [ACK] Seq=3600 Ack=343001 Win=1241 Len=0
TSval=183724761 TSecr=18380709
534 64.225182 192.168.100.99 192.168.44.141 TCP 66
33180 > ms-wbt-server [ACK] Seq=3600 Ack=345897 Win=1241 Len=0
TSval=183724761 TSecr=18380709
535 64.225184 192.168.100.99 192.168.44.141 TCP 66
33180 > ms-wbt-server [ACK] Seq=3600 Ack=347807 Win=1241 Len=0
TSval=183724798 TSecr=18380709
[...skipped...]
562 64.225266 192.168.100.99 192.168.44.141 T.125 127
[TCP Out-Of-Order] T.125 payload
563 64.225305 192.168.100.99 192.168.44.141 T.125 127
[TCP Out-Of-Order] T.125 payload
564 64.225402 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
565 64.225414 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
566 64.225425 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
567 64.225438 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
568 64.225444 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
569 64.225456 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60
192.168.100.99 is at 10:78:d2:eb:43:af
The host system vif interface sees both sides speaking:
676 7.681969 192.168.100.99 192.168.44.141 T.125 [TCP
Retransmission] T.125 payload
677 8.615963 192.168.100.99 192.168.44.141 T.125 [TCP
Retransmission] T.125 payload
678 9.662289 192.168.44.141 192.168.100.99 TPKT [TCP
Retransmission] Continuation
679 9.662995 192.168.100.99 192.168.44.141 TCP [TCP
Dup ACK 677#1] 33180 > ms-wbt-server [ACK] Seq=6162 Ack=477760 Win=1241 Len=0
TSV=183729267 TSER=18380714 SLE=421346 SRE=422794
680 10.483898 192.168.100.99 192.168.44.141 T.125 [TCP
Retransmission] T.125 payload
681 10.899587 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has
192.168.100.99? Tell 192.168.44.141
682 10.899946 Elitegro_eb:43:af Xensourc_19:20:fe ARP
192.168.100.99 is at 10:78:d2:eb:43:af
683 11.899603 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has
192.168.100.99? Tell 192.168.44.141
684 11.900081 Elitegro_eb:43:af Xensourc_19:20:fe ARP
192.168.100.99 is at 10:78:d2:eb:43:af
685 12.899582 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has
192.168.100.99? Tell 192.168.44.141
686 12.899973 Elitegro_eb:43:af Xensourc_19:20:fe ARP
192.168.100.99 is at 10:78:d2:eb:43:af
14.02.2012, 07:55, "James Harper"
<james.harper@bendigoit.com.au>:>> So, you are running a Windows 7 system with less than a gig of RAM?
>> You might start there...bump it to 2 gigs and see if that helps.
>
> That's probably a good start. If that doesn't help things along
then we'll need to start taking packet traces and see if there is a
corruption problem somewhere although it doesn't make sense that it would
just happen in the cases you are describing.
>
> James
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Disabling network throttling in windows registry(kb948066) seems to be solution for this problem. RDP runs smoothly now. 20.02.2012, 16:43, "Kreved" <krevedinho@yandex.ru>:> Traces taken on host and guest systems have shown that the guest stops to receive packets for a period of time, and then gets them all at once. This period of silence depends on rdp-client used: rdesktop-vrdp and mstsc continue to work after a second, rdesktop hangs for one minute and exits on timeout. The host system vif interface sees all incoming and outgoing packets including guest's retransmit attempts. > > Dumping Xen Net Device during rdesktop's one minute freeze shows that guest system(192.168.44.141) becomes blind until rdesktop window closes: > > 513 4.164811 192.168.44.141 192.168.100.99 TPKT 1514 Continuation > 514 4.164815 192.168.44.141 192.168.100.99 TPKT 1514 Continuation > 515 4.164818 192.168.44.141 192.168.100.99 TPKT 1064 Continuation > 516 4.416053 192.168.44.141 192.168.100.99 TPKT 1514 [TCP Retransmission] Continuation > 517 5.017615 192.168.44.141 192.168.100.99 TPKT 1514 [TCP Retransmission] Continuation > 518 6.218786 192.168.44.141 192.168.100.99 TPKT 1514 [TCP Retransmission] Continuation > 519 8.619176 192.168.44.141 192.168.100.99 TPKT 1514 [TCP Retransmission] Continuation > 520 9.856471 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 521 10.856480 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 522 11.856470 Xensourc_19:20:fe Elitegro_eb:43:af ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 523 13.420006 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 524 14.356480 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 525 15.356472 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 526 23.022567 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 527 23.857451 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 528 24.857453 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 529 42.223754 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 530 42.857480 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 531 43.857469 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 532 64.167428 Xensourc_19:20:fe Broadcast ARP 42 Who has 192.168.100.99? Tell 192.168.44.141 > 533 64.225180 192.168.100.99 192.168.44.141 TCP 66 33180 > ms-wbt-server [ACK] Seq=3600 Ack=343001 Win=1241 Len=0 TSval=183724761 TSecr=18380709 > 534 64.225182 192.168.100.99 192.168.44.141 TCP 66 33180 > ms-wbt-server [ACK] Seq=3600 Ack=345897 Win=1241 Len=0 TSval=183724761 TSecr=18380709 > 535 64.225184 192.168.100.99 192.168.44.141 TCP 66 33180 > ms-wbt-server [ACK] Seq=3600 Ack=347807 Win=1241 Len=0 TSval=183724798 TSecr=18380709 > > [...skipped...] > > 562 64.225266 192.168.100.99 192.168.44.141 T.125 127 [TCP Out-Of-Order] T.125 payload > 563 64.225305 192.168.100.99 192.168.44.141 T.125 127 [TCP Out-Of-Order] T.125 payload > 564 64.225402 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > 565 64.225414 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > 566 64.225425 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > 567 64.225438 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > 568 64.225444 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > 569 64.225456 Elitegro_eb:43:af Xensourc_19:20:fe ARP 60 192.168.100.99 is at 10:78:d2:eb:43:af > > The host system vif interface sees both sides speaking: > > 676 7.681969 192.168.100.99 192.168.44.141 T.125 [TCP Retransmission] T.125 payload > 677 8.615963 192.168.100.99 192.168.44.141 T.125 [TCP Retransmission] T.125 payload > 678 9.662289 192.168.44.141 192.168.100.99 TPKT [TCP Retransmission] Continuation > 679 9.662995 192.168.100.99 192.168.44.141 TCP [TCP Dup ACK 677#1] 33180 > ms-wbt-server [ACK] Seq=6162 Ack=477760 Win=1241 Len=0 TSV=183729267 TSER=18380714 SLE=421346 SRE=422794 > 680 10.483898 192.168.100.99 192.168.44.141 T.125 [TCP Retransmission] T.125 payload > 681 10.899587 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has 192.168.100.99? Tell 192.168.44.141 > 682 10.899946 Elitegro_eb:43:af Xensourc_19:20:fe ARP 192.168.100.99 is at 10:78:d2:eb:43:af > 683 11.899603 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has 192.168.100.99? Tell 192.168.44.141 > 684 11.900081 Elitegro_eb:43:af Xensourc_19:20:fe ARP 192.168.100.99 is at 10:78:d2:eb:43:af > 685 12.899582 Xensourc_19:20:fe Elitegro_eb:43:af ARP Who has 192.168.100.99? Tell 192.168.44.141 > 686 12.899973 Elitegro_eb:43:af Xensourc_19:20:fe ARP 192.168.100.99 is at 10:78:d2:eb:43:af > > 14.02.2012, 07:55, "James Harper" <james.harper@bendigoit.com.au>: > >>> So, you are running a Windows 7 system with less than a gig of RAM? >>> You might start there...bump it to 2 gigs and see if that helps. >> That's probably a good start. If that doesn't help things along then we'll need to start taking packet traces and see if there is a corruption problem somewhere although it doesn't make sense that it would just happen in the cases you are describing. >> >> James >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users