http://bugs.winehq.org/show_bug.cgi?id=12302
Summary: Lord of the Rings: Shadows of Angmar unplayable due to high lag Product: Wine Version: 0.9.58. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: brikeener@gmail.com
Lord of the Rings: Shadows of Angmar is very playable with the exception of lag.
Running the game under Mandriva 2008 32 & 64 bit, and Ubuntu 7.04/7.10 32 & 64 bit with wine versions ranging from 0.9.44 to 0.9.58 all eventually render the game unplayable, with high levels of packet loss from saturating my upstream bandwidth.
This is a common complaint on the ubuntuforums and in the appdb. It happens on my desktop PC, my wife's desktop PC, and my work laptop.
http://bugs.winehq.org/show_bug.cgi?id=12302
Brian K brikeener@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |major
http://bugs.winehq.org/show_bug.cgi?id=12302
Alan Jackson ajackson@bcs.org.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajackson@bcs.org.uk
--- Comment #1 from Alan Jackson ajackson@bcs.org.uk 2008-03-31 04:28:06 --- It's also a pretty common complaint for windows users as well (the official forums have quite a few posts about this problem). It isn't a wine bug, it isn't even a linux bug (though some wireless cards do suffer worse under linux due to poor drivers).
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #2 from Brian K brikeener@gmail.com 2008-03-31 08:59:29 --- Lag is always a complaint in online games.
The game is unplayable under Linux for Ubuntu 32 and 64-bit, and Mandriva 32 and 64-bit, using any wine version more recent than 0.9.44 (the earliest I've tried.)
The same physical hardware and network connection is capable of playing the game with no lag under Windows XP, XP64, and Vista 32 and 64 bit.
The linux install was even tried using the physical LOTRO installation folder from the XP 32-bit install, to no avail.
There's no packet loss when I ping and traceroute the physical servers, from any operating system.
The only commonality is that it works without Wine, and it fails to work with Wine.
http://bugs.winehq.org/show_bug.cgi?id=12302
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
http://bugs.winehq.org/show_bug.cgi?id=12302
Mikko Korkalo mikko@korkalo.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikko@korkalo.fi
--- Comment #3 from Mikko Korkalo mikko@korkalo.fi 2008-03-31 14:38:18 --- I can confirm this bug. I also had no problems under Windows. I know know at least two other people from top off my head who have exactly the same problem.
Here's my original bug report, which I sent to Turbine Monday December 31st 2007, 21:15. http://keitsi.minttupuffet.net/misc/lotrobug.txt
I never received a reply from them.
If you need any more information, don't hesitate to contact me. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #4 from Mikko Korkalo mikko@korkalo.fi 2008-03-31 14:46:30 --- This seems to be entirely seasonal. Sometimes I can play 5 hours without noticeable problems, and sometimes I get 2 hours of BAD lag. When this occurs, there is a thread in lotroclient.exe which is running at 100% cpu, apparently generating packets.
I can get a backtrace if required.
http://bugs.winehq.org/show_bug.cgi?id=12302
Athrun samurai_no_densetsu@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |samurai_no_densetsu@yahoo.es
--- Comment #5 from Athrun samurai_no_densetsu@yahoo.es 2008-04-06 10:12:41 --- Personally never had any heavy lag issues, but as current mantainer of the LOTRO: Shadows of Angmar on AppDB, I had observed that some people does. After giving help to some of them, I agree with Alan Jackson, it's a hardware dependant issue more than a wine bug, the fact is that most of hardware runs flawless the game while other, maybe caused by drivers, have flaws. In my oppinion its like the nVidia/Ati/intel graphics well know issue. So, most likely, there is nothing that can be fixed on the wine side.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #6 from Mikko Korkalo mikko@korkalo.fi 2008-04-06 12:11:30 --- Let's try to see what is the difference in setups with no lag and with lag?
My hardware: - Intel Core 2 Quad Q6600 - Intel D975XBX2 mobo (975X chipset) - NVIDIA 8600GTS - 4GB DDR2 800MHz
Software: - wine 0.9.47 to 0.9.58 tested - Kubuntu 7.10 64bit - 2.6.22-14-generic SMP kernel - nvidia drivers 100.14.19 and 169.09 tested, also few other versions which I don't remember
The game generates enough traffic to fill my 1 Mbit upsteam, causing heavy lag sometimes. I have been playing for about 4 months, been the same since beginning.
http://bugs.winehq.org/show_bug.cgi?id=12302
Ville Jussila villeju@paju.oulu.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |villeju@paju.oulu.fi
--- Comment #7 from Ville Jussila villeju@paju.oulu.fi 2008-04-06 15:14:29 --- I can also confirm this bug. Symtoms are exactly same as Mikko explains.
My current configuration:
Debian 4.0 (etch) 64bit Wine 0.9.53 (tried also older ones) Nvidia 169.09 drivers Custom 2.6.23.8 linux kernel
Hardware: Intel Q6600 Nvidia 8600GT 4GB ddr2
Upstream what Lotro generates are about ~7Mb but even with my 10/10 connection Lotro still lags quite heavily.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #8 from Athrun samurai_no_densetsu@yahoo.es 2008-04-06 18:40:29 --- Well here is my setup, but I don't think there is anything special.
Hardware: - AMD Athlon64 3200+ - KT800Pro Mainboard - Nvidia 7600GT 256MB - 1GB DDR1 Platinum Memory
Tested with the following software: - Ubuntu 6.06, 6.10, 7.10, all of these 32bit - Wine from version 0.9.45 to 0.9.55 (I build every version I test) - Nvidia drivers 87.76, 100.14 and 169.09
In my oppinion, the following is the key of the matter
Tested with two different network cards - VIA Rhine II (integrated) - 3Com 3C905CX-TX-M (Pci) With: - 1Mbit upstream / 12Mbit downstream
And from where I can recall, about five or six months playing LOTRO, I only remember having overkill lag a couple of times.
Of course, that aren't cutting edge network cards, even may be 'aged', but fully supported and stable, with mature in drivers. Maybe that's a reason.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #9 from Brian K brikeener@gmail.com 2008-04-09 14:24:50 --- I tried a few older pci ethernet cards, including a Linksys LNE100TX (tulip) and some generic Rhine adapter I had laying around.
No change at all, still nothing but lag.
Windows is still smooth as silk.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #10 from Mikko Korkalo mikko@korkalo.fi 2008-04-09 15:45:40 --- I have an integrated Intel e1000. I am pretty confident this is not the fault of the NIC driver.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #11 from Athrun samurai_no_densetsu@yahoo.es 2008-04-11 07:17:37 --- Hmm... let me think...
I remember a setup wich LOTRO was unplayable due 'lag', but it ended being related to poor filesystem performance (I think that also NCQ had some impact performance in that case).
And was solved modifiying /etc/fstab in this way:
/dev/sda1 /boot defaults,notail 0 0 /dev/sda3 / ext3 defaults 0 0 /dev/sda5 /mnt/sda5 xfs defaults 0 2 /dev/sda6 /mnt/sda6 ext2 defaults 0 2
to
/dev/sda1 /boot defaults,notail 0 0 /dev/sda3 / ext3 rw,noatime,nodiratime 0 0 /dev/sda5 /mnt/sda5 xfs rw,noatime,nodiratime 0 2 /dev/sda6 /mnt/sda6 ext2 rw,noatime,nodiratime 0 2
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #12 from Athrun samurai_no_densetsu@yahoo.es 2008-04-11 07:46:14 --- Hmm... let me think...
I remember a setup wich LOTRO was unplayable due 'lag', but it ended being related to poor filesystem performance (I think that also NCQ had some impact performance in that case).
And was solved modifiying /etc/fstab this:
/dev/sda1 /boot reiserfs defaults,notail 0 0 /dev/sda3 / ext3 defaults 0 0 /dev/sda5 /mnt/sda5 xfs defaults 0 2 /dev/sda6 /mnt/sda6 ext2 defaults 0 2
To this:
/dev/sda1 /boot reiserfs defaults,notail 0 0 /dev/sda3 / ext3 rw,noatime,nodiratime 0 0 /dev/sda5 /mnt/sda5 xfs rw,noatime,nodiratime 0 2 /dev/sda6 /mnt/sda6 ext2 rw,noatime,nodiratime 0 2
Actually rw,noatime,nodiratime options are safe an deliver between 10%~50% IO performance boost as the filesystem don't write every time that writes/reads a file to update the last access time.
It can appear insignificant, but mind on it, just every time a read or write is performed, atime writes again to hardisk, and harddisk (or flash drives) are the slowest part on modern PCs if we ignore optical media drives.
Please try and report.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #13 from Mikko Korkalo mikko@korkalo.fi 2008-04-11 17:26:50 --- I tried as suggested and moved ~/.wine into an ext2 drive which I mounted with noatime,nodiratime. No change.
I wrote a perl script to take latency and bandwidth usage stats, and used openoffice to show them in the same graph. Here, a very simplified picture: http://www.korkalo.fi/lotro_lag.png
The IP address there is one of the lotro servers the game connects to. Upstream usage was measured simply by reading from /proc, and latencies by the ping command.
Here's the full speadsheet with raw data: http://www.korkalo.fi/lotro_lag.ods
This clearly shows that: - Lotro generates a lot of traffic for a moment (5 Mbit for a moment) - The traffic amount affects latency to lotro server
Here's a full bzipped traffic capture of everything being sent and received: http://www.korkalo.fi/lotro_lag.trace.bz2 You can open it with wireshark for analyzation. I've changed my account password after the dump, so please don't waste your time trying to crack it. ;-) Also at the end of capture I downloaded with full downstream from ftp.funet.fi just to test how it looks in the statistics, you can just ignore it.
Here's the perl script I used to create the statistics: http://www.korkalo.fi/bw_ping.pl
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #14 from Mikko Korkalo mikko@korkalo.fi 2008-04-12 06:25:46 --- A note about my last post. Timeouts have been replaced with 600ms to show them properly in the graph.
http://bugs.winehq.org/show_bug.cgi?id=12302
Tapio Haapala tapio.haapala@f-solutions.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tapio.haapala@f- | |solutions.net
--- Comment #15 from Tapio Haapala tapio.haapala@f-solutions.net 2008-04-12 06:39:55 --- I think this has nothing to do with hardware. Maybe for some reason some threads do not sleep properly, which causes the thread to send packets too fast? Maybe problem is in some kind of clock(tick) emulation or in interrupt emulation? I think this is a wine bug and there is no way that this kind of packet flood from software to ip stack can come from network drivers. That speculation of filesystem issue is madness.
http://bugs.winehq.org/show_bug.cgi?id=12302
Tapio Haapala tapio.haapala@f-solutions.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #16 from Tapio Haapala tapio.haapala@f-solutions.net 2008-04-12 06:40:47 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #17 from Athrun samurai_no_densetsu@yahoo.es 2008-04-12 09:52:31 --- (In reply to comment #15)
That speculation of filesystem issue is madness.
Not really, it affected a couple of users complainting lag, but in their case that solved it, in my oppinion the suposed 'lag' they were suffering was a side effect of a sluggish I/O performance.
Ok, maybe its a bug after all... but is strange that only affects some systems while others run flawless, don't you agree?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #18 from Mikko Korkalo mikko@korkalo.fi 2008-04-13 03:40:54 ---
Not really, it affected a couple of users complainting lag, but in their case that solved it, in my oppinion the suposed 'lag' they were suffering was a side effect of a sluggish I/O performance.
In this case the lag is a side effect of LOTRO generating a lot of traffic.
Ok, maybe its a bug after all... but is strange that only affects some systems while others run flawless, don't you agree?
I'd like to see specs from the users that run the game flawlessly.
Also, it might be worth noting that some people might not even notice the extra traffic. Maybe with some players the amount of generated traffic is less than on others. Also some people have higher bandwidth capacity than others. With 10/10M bandwidth the lag is rarely noticeable, because the upload peak rarely gets up to 10M. --> Higher upstream capacity, less lag.
While playing, could you (and others) run the bw_ping.pl script on some box that runs the game well? That way we know for sure that the game doesn't generate extra traffic.
You can run the script like this: wget http://www.korkalo.fi/bw_ping.pl chmod +x bw_ping.pl ./bw_ping.pl 195.33.152.173,google.com,`ip route|tail -1|awk '{print $3}'`,localhost eth0 --interval=2 > /dev/shm/lotro_stats.csv
- Here I am directing statistics to shared memory device, to avoid any extra I/O load on harddrives. - 195.33.152.173 is IP of some UK lotro server, you might want to replace that with the one that you are using. You can find out with wireshark or netstat.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #19 from Tapio Haapala tapio.haapala@f-solutions.net 2008-04-13 03:55:01 --- (In reply to comment #17)
(In reply to comment #15)
That speculation of filesystem issue is madness.
Not really, it affected a couple of users complainting lag, but in their case that solved it, in my oppinion the suposed 'lag' they were suffering was a side effect of a sluggish I/O performance.
Ok, maybe its a bug after all... but is strange that only affects some systems while others run flawless, don't you agree?
Well on all cases what I know it generates extra network traffic and that traffic cause that lag. How you think that filesystem I/O performance problems generates 5Mbps extra traffic to network? If you read that bugreport you see that problem is not just a lag. Its side effect of abnormal heavy network traffic from game. How it is so hard to understand
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #20 from Athrun samurai_no_densetsu@yahoo.es 2008-04-13 15:05:33 --- Ok here is my test, I have tested it in my usual setup:
Ubuntu 7.10 32bits, wine 0.9.57 (as always compiled by myself), Nvidia drivers 169.09, 1Mbit upstream / 12Mbit downstream internet connection, the rest the are same from my setup post above.
And the results are the following.
Test time: one hour of full gameplay. Max upstream Kbps 2413320 hitted a single time. Upstream range 2000000-1000000 hitted 15 times. Rest of upstream hits are below 1000000 and 500000. Total timeouts 19, wich is a timeout for every 3,15 minutes of gameplay. Timeouts were replaced with 600ms in the graph as Mikko did.
Here is my graph http://img329.imageshack.us/img329/4941/lotrolagtestathrunqp9.png
Gameplay was smooth, I sensed a couple of jumps, but nothing that will lead to unplayable. Also I will test it more on weekend when the server are full. I agree that there is a bug, but it affect more some hardware (or router, internet provider or something) than other.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #21 from Mikko Korkalo mikko@korkalo.fi 2008-04-13 15:49:04 --- Thank you for the test. I'd like to see more, but this already tells a lot.
One thing about the bw_ping.pl script. There are really more timeouts than shown on the graph, because every time timeout occurs, the ping command will block the script longer. (That script was a quick hack I had to write to do something last year) Maybe I should look into rewriting it with python to use threading to overcome this problem...
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #22 from Mikko Korkalo mikko@korkalo.fi 2008-04-13 17:10:37 --- Someone should change the bug name, I think this is a bit misleading. Devs might read the report quickly and figure it's a FPS lag issue (and just ignore the bug). Maybe "Lord of the Rings: Shadows of Angmar floods massive amount of UDP packets" would be better. This really is important, in the worst case Turbine might take actions to prevent any wine player from playing. I can imagine this is hard for their servers and connections.
Think, 1000 wine players with 1 Mbps upstream capacity flooding servers.
http://bugs.winehq.org/show_bug.cgi?id=12302
Jim McDonald Jim@mcdee.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Jim@mcdee.net
--- Comment #23 from Jim McDonald Jim@mcdee.net 2008-04-26 15:37:31 --- I have been seeing this issue and looking at the network traffic there were a lot of UDP packets with bad checksums. I'm not sure if this was having an effect or not but for those who are seeing lots of lag can you try:
ethtool -K eth0 tx off
as root, and replacing eth0 with your outgoing interface if required. Doing this has taken my packet loss down from intermittently unplayable to 0.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #24 from Brian K brikeener@gmail.com 2008-04-26 19:28:15 --- Thanks for the advice, but this had no impact on my lag.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #25 from Mikko Korkalo mikko@korkalo.fi 2008-04-27 08:03:20 --- Jim: I don't believe UDP checksum has nothing to do with it. In the capture, you see bad checksums because the driver offloads checksum calculation to the network card (thus wireshark sees all checksums as zeroes which causes it to say they're invalid).
I think it is just a coincidence that the ethtool command had effect: sometimes there is no lag, sometimes there is. How long did you try playing after issuing the command?
http://bugs.winehq.org/show_bug.cgi?id=12302
Andreas Blochberger andreas@blochberger.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas@blochberger.net
--- Comment #26 from Andreas Blochberger andreas@blochberger.net 2008-05-02 05:13:25 --- I have had this lag problem also. After switching my router, the massive packet loss almost disappeared. With the Fritz!Box 7170 there was this massive packet loss, but only in Linux/Wine With my old Siemens SX541 there is no lag anymore. No hardware/software changes other than the router solved this issue for me.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #27 from Mikko Korkalo mikko@korkalo.fi 2008-05-04 08:06:45 --- (In reply to comment #26)
With my old Siemens SX541 there is no lag anymore.
Can you please try playing longer?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #28 from Andreas Blochberger andreas@blochberger.net 2008-05-04 09:38:07 --- (In reply to comment #27)
(In reply to comment #26)
With my old Siemens SX541 there is no lag anymore.
Can you please try playing longer?
Just yesterday, i played for about 6-7 hours, hanging around in Urugarth. Before i switched my router, i had a packet loss rate round about 20%-50%, now when things are very bad, the loss rate is 1%-3% The problem with my Fritz!Box was, when playing Lotro, the router crashed on this tremendous amount of bogus packets. There's a thread in the european codemasters forum about that from me: http://community.codemasters.com/forum/showthread.php?t=269211 I do not think, its the router alone. But for sure, its a bug in the Lotro client.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #29 from Andreas Blochberger andreas@blochberger.net 2008-05-11 07:43:05 --- Lag returned with Fritz!Box WLAN 7170. so here's my hw/sw list:
Hardware: - Intel Core 2 Quad 6600 - Giga-byte RTL8111/8168B PCI Express Gigabit Ethernet controller - GeForce 8600 GTS - Fritz!Box WLAN 7170 (bad) / Siemens SX541 (better)
Software: - openSUSE 10.3 64 bit (Linux version 2.6.22.17-0.1-default) - wine-1.0-rc1 - NVIDIA UNIX x86_64 Kernel Module 169.12
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #30 from Andreas Blochberger andreas@blochberger.net 2008-05-11 08:38:10 --- I was trying to find out what happens on the network layer, so i turned on logging for winsock, setting WINEDEBUG=-all,+winsock
Strange enough, in this play session i did not have any packet loss (max 2%) The only thing i found in the log is this warning: warn:winsock:WSARecvFrom -> ERROR 10035
So i started another session, and this time, lag was here again. But not in every zone. It seems Zigilgund in Forochel is very laggy.
Sometimes, the above comes twice. I will try to start a session with my Siemens router and see, if things are different.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #31 from Andreas Blochberger andreas@blochberger.net 2008-05-11 10:33:08 --- After looking at the source in socket.c i think there must be something wrong. It seems, that the lotro client is using non-blocking sockets to read data. But in my logs i didn't find any successful call to WSARecvFrom. It's been a long time ago, since i had to bother with windows IP communication, so i am not that firm in that area. here is the log for one call: trace:winsock:WSARecvFrom socket 018c, wsabuf 0x7bbfe90c, nbufs 1, flags 0, from 0x212b8c8, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=76, options=0 warn:winsock:WSARecvFrom -> ERROR 10035
The socket is created this way: trace:winsock:WSASocketW af=2 type=2 protocol=0 protocol_info=(nil) group=0 flags=0x1
There is a fixme in that function, but in this case, the only flag given is WSA_FLAG_OVERLAPPED
So, lotro calls WSARecvFrom on an overlapped socket without providing an lpOverlapped structure. Maybe this is the reason, why lotro sends out so mayn packets, because it thinks, it didn't receive an answer, though it did... but that#s just wild speculation...
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #32 from Andreas Blochberger andreas@blochberger.net 2008-05-11 11:15:21 --- Maybe i have some explanation, why some people have issues, and others don't. A tracerout comparison of the US server versus the european servers: traceroute to gls.lotro.com (206.16.13.82), 30 hops max, 40 byte packets 1 router (192.168.2.1) 0.308 ms 0.341 ms 0.419 ms 2 L0.nbg2-lns.mcbone.net (62.104.190.39) 45.670 ms * * 3 ge-1-0-0-2.nbg2-j.mcbone.net (62.104.219.7) 44.583 ms 43.896 ms 43.755 ms 4 ge-3-0-0-0.ffm4-j.mcbone.net (62.104.200.132) 47.781 ms 48.035 ms 47.975 ms 5 t2a7-ge0-3.de-fra.eu.bt.net (166.49.148.137) 48.641 ms 48.137 ms 49.790 ms 6 t2c1-ge12-0-0.de-fra.eu.bt.net (166.49.172.97) 48.144 ms 48.171 ms 48.500 ms 7 t2c1-p10-0.uk-glo.eu.bt.net (166.49.195.77) 68.475 ms 68.121 ms 69.007 ms 8 t2c1-p9-0.uk-eal.eu.bt.net (166.49.208.9) 68.451 ms 69.582 ms 67.632 ms 9 t2c1-p5-0-0.us-ash.eu.bt.net (166.49.164.65) 154.591 ms 154.845 ms 155.313 ms 10 12.118.44.37 (12.118.44.37) 147.756 ms 147.473 ms 147.493 ms 11 tbr1.wswdc.ip.att.net (12.122.80.194) 163.683 ms 163.603 ms 163.539 ms 12 cr2.wswdc.ip.att.net (12.122.16.5) 168.361 ms 166.737 ms 164.503 ms 13 cr2.n54ny.ip.att.net (12.122.3.37) 163.396 ms 164.155 ms 165.228 ms 14 cr1.cb1ma.ip.att.net (12.122.31.126) 164.834 ms 163.066 ms 162.781 ms 15 tbr1.cb1ma.ip.att.net (12.122.20.138) 163.607 ms 164.313 ms 163.402 ms 16 12.127.5.93 (12.127.5.93) 163.304 ms 162.761 ms 162.373 ms 17 12-122-254-14.attens.net (12.122.254.14) 164.980 ms 163.248 ms 163.088 ms 18 mdf001c7613r0004-gig-12-1.bos1.attens.net (12.130.0.174) 163.356 ms 163.031 ms 163.146 ms 19 12.130.10.69 (12.130.10.69) 164.118 ms 164.295 ms 164.512 ms 20 206.16.13.82 (206.16.13.82) 164.112 ms 163.830 ms 164.772 ms
And here are the results of the european server: traceroute to lotroeugls.com (195.33.152.240), 30 hops max, 40 byte packets 1 router (192.168.2.1) 0.532 ms 0.319 ms L0.nbg2-lns.mcbone.net (62.104.190.39) 45.094 ms 2 ge-1-0-0-200.nbg2-j.mcbone.net (62.104.195.3) 46.367 ms 44.645 ms 44.120 ms 3 ge-3-0-0-0.ffm4-j.mcbone.net (62.104.200.132) 47.298 ms 47.034 ms 47.093 ms 4 dcix1nap.de.ip.att.net (80.81.192.199) 47.837 ms 48.603 ms 48.256 ms 5 nlamtr1103er1-0-0.am.nl.ip.att.net (165.87.217.34) 55.516 ms 55.142 ms 54.982 ms 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #33 from Mikko Korkalo mikko@korkalo.fi 2008-05-12 15:28:01 --- Traceroute is probably being blocked by a firewall. What does that tell us?
http://bugs.winehq.org/show_bug.cgi?id=12302
Jumper ned_fed@tiscali.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ned_fed@tiscali.it
http://bugs.winehq.org/show_bug.cgi?id=12302
Constantin Bergemann cbergemann@gmxpro.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cbergemann@gmxpro.de
http://bugs.winehq.org/show_bug.cgi?id=12302
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.vankaam@chello.nl
--- Comment #34 from Caladan a.vankaam@chello.nl 2008-05-29 14:39:41 --- Here are the results of the bw_ping script, could not get it to a nice graph, but am sure someone can.
http://members.chello.nl/~a.vankaam/lotro/lotr-29-05.csv
this is almost 1 hour play, in Evendim, Barandalf, the last 5min are from there to Tinnudir.
I am not sure if this is the same lag you are refuring to, basicly it feels like your on an elastik band, getting pulled back each time.
What I did notice is that south area of Barandalf it ran smooth, north area it started to lag, at first I thought this might be related to loading new gfx but drive was not really active. I dunno how to explain, but on my way to Tinnudir you go through north Barandalf and kings bridge, close to kings bridge the lag stopped again. I am not sure how zone's work in lotro but could it somehow have anything to do with moving from one zone into another.
I dont think its drive related, I can believe that if I enter an area 1st time but each time I came close to the north it happened, move south and it would stop, move further north towards kings bridge and it would happen and then suddenly stop. During that time not much harddisk activity. Stopping (in case it was slow harddisk) so system could catch up had no result.
Hardware: - Intel Core 2 Quad 6700 - Marvell 88e8053 dual gigabit LAN (onboard) - GeForce 8800 GT
Software: - openSUSE 10.3 32 bit (Linux 2.6.22.17-0.1-bigsmp i686) - wine-1.0-rc1 - NVIDIA 1 click driver (last version)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #35 from Mikko Korkalo mikko@korkalo.fi 2008-05-29 15:54:54 --- Here is a graph I made from Caladan's CSV: http://www.korkalo.fi/lotro_lag_Caladan.png
It clearly proves that: 1) There is a lot of upload, even 10 Mbit (20000 packets/s) peaks 2) There is lag (as obviously expected) which happens the same time as the upload peaks
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #36 from Caladan a.vankaam@chello.nl 2008-05-29 22:52:30 --- thank you Mikko, would be intresting to see if you can/have the same behaviour in the same area: Evendim, Barandalf, the beach part is fine, all the way up north to where the road enters the green hills (where the lag starts) and after a bit ends (before you reach kings crossing)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #37 from Athrun samurai_no_densetsu@yahoo.es 2008-05-30 09:27:36 --- Ok after reading this on morning I have tested myself a couple hours ago.
This was my result:
http://img88.imageshack.us/img88/1135/lotro2ndlagtestathrunmn8.png
It was a little more than an hour, splitted in a roughtly 1/3 of the time, first part was Everdim, then Tinnudir, and lastly Barandalf.
I sensed no lag except on Everdim, but even it was very playable I agree with Mikko:
It clearly proves that:
- By some reason there are a lot of upload in several moments.
- There is lag (as obviously expected) which happens the same time as the
upload peaks
And I should add
3) It might be a bug somewhere 4) Even agreeing that there might be a bug, it seems to affect more to some network hardware/router than other (as not every one are suffering it that hard).
And I think that more tests will drop light into this, and are welcome.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #38 from Andreas Blochberger andreas@blochberger.net 2008-06-02 01:14:09 --- Without the help from Turbine, this issue cannot be solved, i guess. After all i don't think it's a bug in wine. But this doesnt mean, there cant be done anything on the wine side. Are there any network stress tests for the wine network layer? It would be nice to have some MMO-like client/server test that can give some comparison between native windows and wine
http://bugs.winehq.org/show_bug.cgi?id=12302
Jörg Selbach sidolin@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sidolin@gmx.net
--- Comment #39 from Jörg Selbach sidolin@gmx.net 2008-06-14 11:56:09 --- I've just updated to 1.0rc5 and the lags seem to be gone (with 1.0rc3 the game lagged unplayably, my whole X session froze for around 3-5 seconds every 20 seconds with one cpu core using 100% IO time). I've wandered around Bree for about one hour and nothing happened (with many players walking around on a saturday evening), can anyone confirm this?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #40 from Caladan a.vankaam@chello.nl 2008-06-15 01:44:59 --- the lag wich gives you the elastic band effect in-game because of the high network trafic is still there in rc5. It's still very much area related, I can ride through trollshaw without any issue except on a few spots where loss goes from 0.1% to 6-10% and latency goes from 19ms to 500ms or more.
Good spot to test in trollshaw is Drauglad, lag-less 35.1S, 13,7W, move west to 35.1s and 14.0W and its lag time.
here is the info from a small test standing still at 2 specific spots:
http://members.chello.nl/~a.vankaam/lotro/drauglad.csv
8:24:00 I am stainding at 35.1S, 13.7W, ingame latency 18ms, loss 0,2% 8:25:00 I start to move west towards 35.2S, 14.1W 8:25:15 I reach 35.2S, 14.1W, ingame latency up to 500ms, loss 9% 8:26:15 I start to move back towards 35.1S, 13.7W 8:26:35 I reach 35.1S, 13.7W, ingame latency down to 18ms, loss still around 8%, it takes about 30sec or so for loss to get back to 0,2%
I know its a small test but it shows same as I had in Evendim, specific area will trigger it, and thus I can reproduce it as much as I want.
There no X session issues, UK server (Snowborn)
-Cal
http://bugs.winehq.org/show_bug.cgi?id=12302
Pablo kydorn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kydorn@gmail.com
--- Comment #41 from Pablo kydorn@gmail.com 2008-06-23 04:11:53 --- I can confirm this. I'm using ubuntu 8.04 and wine 1.0
LotRO seems to be sending thousands of UDP packets, making a denial-of-service attack to my router. Consequently, lag increases and the game is not playable.
http://bugs.winehq.org/show_bug.cgi?id=12302
Pablo kydorn@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kydorn@gmail.com
--- Comment #41 from Pablo kydorn@gmail.com 2008-06-23 04:11:53 --- I can confirm this. I'm using ubuntu 8.04 and wine 1.0
LotRO seems to be sending thousands of UDP packets, making a denial-of-service attack to my router. Consequently, lag increases and the game is not playable.
--- Comment #42 from Caladan a.vankaam@chello.nl 2008-06-23 11:15:18 --- I have read here that windows people also complain about lots of network traffic but it seems its not as much as we are getting else it would be a much bigger issue (I also dont have it on the same pc under windows). Several Linux users here say they dont have the problem either so could it be a combination of wine (and its network stuff), linux (and its network stuff) and specific hardware ? It seems its not linux distribution related as ubuntu and suse both are mentioned here. If so how would we go about to debug this ? see if those that have it have something incomen ? specific logs / info ?
http://bugs.winehq.org/show_bug.cgi?id=12302
Delmar delmar@nzgate.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |delmar@nzgate.com
--- Comment #43 from Delmar delmar@nzgate.com 2008-06-29 06:32:01 ---
I'm pleased to find I am not the only one with this issue, but also sad because this is a real curly one... and I don't like the chances of this being resolved this side of Christmas :(
System: Core2 Quad Q6600 MemTotal: 8194260 kB MB: Gigabyte EP35-DS3R thingie www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=2740
On-board Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit...thingie
Ubuntu Hardy 64bit. 1.1.0~winehq0~ubuntu~8.04-1 Kernel 2.6.24-19-generic SMP x86_64 etc.
After some testing I have come to the conclusion that this 'LAG' is most certainly a network issue generated by the lotro client when being used with Linux+Wine.
As so many other people have described, I have witnessed the LOTRO client bursting a huge number of UDP packets, flooding my upstream connection and trashing everything in it's path. This even occurred when standing still and not even moving.
Booting into WinXP 64bit and running around the same area barely uses more than 15Kbps upstream and never bursts packets at all.
I guess I will hold onto this old WinXP partition a while longer...:(
http://bugs.winehq.org/show_bug.cgi?id=12302
Delmar delmar@nzgate.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |delmar@nzgate.com
Richard anthonyd182@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anthonyd182@gmail.com
--- Comment #43 from Delmar delmar@nzgate.com 2008-06-29 06:32:01 ---
I'm pleased to find I am not the only one with this issue, but also sad because this is a real curly one... and I don't like the chances of this being resolved this side of Christmas :(
System: Core2 Quad Q6600 MemTotal: 8194260 kB MB: Gigabyte EP35-DS3R thingie www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=2740
On-board Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit...thingie
Ubuntu Hardy 64bit. 1.1.0~winehq0~ubuntu~8.04-1 Kernel 2.6.24-19-generic SMP x86_64 etc.
After some testing I have come to the conclusion that this 'LAG' is most certainly a network issue generated by the lotro client when being used with Linux+Wine.
As so many other people have described, I have witnessed the LOTRO client bursting a huge number of UDP packets, flooding my upstream connection and trashing everything in it's path. This even occurred when standing still and not even moving.
Booting into WinXP 64bit and running around the same area barely uses more than 15Kbps upstream and never bursts packets at all.
I guess I will hold onto this old WinXP partition a while longer...:(
--- Comment #44 from Richard anthonyd182@gmail.com 2008-07-01 12:47:13 --- One thing I have noticed with this issue, is that in my case I have noticed that the game begins to have large amounts of packet loss only when I do actions that require extra data upload to the server (ex: Attacking enemys, looting corpses). If I do not do anything at all and just stand in one spot, I get relatively low % packet loss ( 0.9 to 20% ). But, if I get more then about 90% packet loss then stand still, my connection will gradually get better over time.
http://bugs.winehq.org/show_bug.cgi?id=12302
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.santos@pobox.com
--- Comment #45 from Daniel Santos daniel.santos@pobox.com 2008-07-07 06:40:07 --- This bug is getting rather annoying to me. What is the best way to debug apps running under Wine, the m$ visual crap studio tools or native Linux debuggers like gdb & Kdevelop? I'm guessing I would have to rebuild wine with debugging symbols included.
Is anybody on the wine team working this issue already? I'm not terribly talented at reverse engineering compiled C/C++ code and I don't know x86 assembly very well at all, but I'm willing to give it my best shot. If this problem is indeed caused by the lotro client, I'm hoping that at least a reliable pattern can be detected that can tell wine that lotro is screwing up and just politely not transmit the requested spam.
Has anybody compiled information yet on the lotro's network protocol? I'm presuming it's a UDP-based proprietary protocol. Ooh, or maybe Turbine would give us the sources if we just asked politely :) hehe.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #46 from Mikko Korkalo mikko@korkalo.fi 2008-07-07 10:17:38 --- (In reply to comment #45)
Is anybody on the wine team working this issue already?
AFAIK, no one has opted in yet.
Ooh, or maybe Turbine would give us the sources if we just asked politely :) hehe.
I tried that - no answer yet :) It's been months since I filed a bug report via the bug report form.
Also there's a thread at codemasters forum. I'm guessing they're reading it: http://community.codemasters.com/forum/showthread.php?t=269211
I suggest that everyone suffering from the problem posts there.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #47 from Daniel Santos daniel.santos@pobox.com 2008-07-07 13:51:56 --- Thanks for the response. I guess I'm "it" then. Let me make this really really simple. I ran wireshark and went through an area I knew had problems. In a one particular 0.499944 second time frame (I presume timing was aimed at half a second) the lotro client sent 8530 identical UDP packets at 62 bytes each (19 bytes of actual date, the rest headers). That's a very short time for half a MB of data. But also keep in mind that routers and even the local machine has to do processing for each packet (probably what kills some routers with this bug). Furthermore, I've located evidence (http://forums.lotro.com/showthread.php?t=79612) that a variation of this bug has existed for windows users in the past, propping up the supposition that this is an inherent lotro client bug.
I propose a very simple hack that detects when the same packet is being sent within a 1 second time frame that will simply drop the additional packets. It may be possible to refine it further by looking for some opcode in the packet. I'm wondering if this can actually be done in netfilter, at least as a temporary solution. But I barely know where to start in wine. My hope is that there is a "hacks" library of some type somewhere to contain hacky work-arounds for crappy applications like this one to keep them out of everything else. I guess I need to start surfing and trolling, err, I mean visiting the wine chat room :)
If nothing else, I can make a patch for winsock.c that will be for use only for people running lotro (an ugly idea IMO).
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #48 from Mikko Korkalo mikko@korkalo.fi 2008-07-07 20:44:10 --- (In reply to comment #47)
I propose a very simple hack that detects when the same packet is being sent within a 1 second time frame that will simply drop the additional packets.
This could work. I guess it would be easiest to write this as a netfilter match module. For example: iptables -A FORWARD -s 1.2.3.4 -p udp -m multiport --dports x,y,z -m length --length 1:100 -m filterdupes -j DROP
Since the packets are so small, I guess checksumming them by CPU wouldn't be a problem. Another method could be to always cache the last packet, and once a new packet is queued, do a byte by byte comparision (probably faster than checksumming?).
Sounds doable, assuming that the additional scanning won't cause too much CPU load. I would start off by fetching and modifying source code for some simple match module, such as "length".
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #49 from Daniel Santos daniel.santos@pobox.com 2008-07-08 07:22:06 --- Created an attachment (id=14652) --> (http://bugs.winehq.org/attachment.cgi?id=14652) hack to work-around lotro client spam bug
(In reply to comment #48) hmm, too bad I didn't read your post earlier. I just implemented a cute little hack in dlls/ws2_32/socket.c that resolve the issue!! The only problem is that it's a hack and can't be put into the source tree, instead, lotro users will have to download the patch & compile the modified ws2_32.dll.so, etc. If you know how to do this with netfilter, that would work better. Here is what I found that works:
If the same packet is sent more than 2 times within a 83 millisecond time frame (1/12th of a second) then drop additional duplicates. After that time elapses, reset the counter (allow another 2 basically). Only for UDP packets Possibly we can restrict this to a few ports, 9002 & 9008 seem to be where this problem occurs, but I haven't tested that restriction.
Either way, I'm attaching the socket.c hack for this. Perhaps we can compile some binaries as well and post them to make it easier. I personally found it quite challenging to custom compile wine on an amd64 box (but it was my 1st attempt too)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #50 from Daniel Santos daniel.santos@pobox.com 2008-07-08 08:21:49 --- ok, ixnay on that last patch, there are now thousands of non-identical packets getting through. I may be passing the number of bytes back incorrectly causing it to try again in a different way. Will have to investigate further.
(In reply to comment #48)
This could work. I guess it would be easiest to write this as a netfilter match module. For example: iptables -A FORWARD -s 1.2.3.4 -p udp -m multiport --dports x,y,z -m length --length 1:100 -m filterdupes -j DROP
Ok, so I'm reading up a little bit on doing this. I like this solution WAY better because it keeps the wine layer squeaky clean, even though it will result in significantly greater CPU usage (doesn't mean the CPU usage its self will be significant though). It it turns out that the spamming is also causes CPU problems, then we can look more seriously at the wine-layer hack.
So if I'm understanding this correctly, we would just write a filterdupes netfilter module, preferably that accepts some parameters and add a rule that looks something like this:
iptables -A FORWARD -p udp -m multiport --dports 9002,9008 -m length --length 1:100 -m filterdupes --cache-duration 85 --dupes-allowed 2 -j DROP
Is the source address really needed? I would pin down the destination addresses, but that changes for each server and possibly even for the same "server", since they may have (one would hope) a cluster of actual machines. Also restricting to UDP and ports 9002 & 9008 should keep it from interfering with other apps.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #51 from Caladan a.vankaam@chello.nl 2008-07-08 11:11:32 --- This sounds cool, but I think filterdupes is something someone should write for iptables ? (yes new to all this :) ) I doubt the cpu load for checksumming the udp packages will be more then the cpu load generated by these bursts of udp packages right now. Anyways, more then willing to test.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #52 from Thomas Benn sotis@gmx.net 2008-07-09 15:58:44 --- So... DOES the above iptables rule work or is it just an idea? Does the filterdupes thing exist? I get an error that it can't be found after installing iptables on my gentoo machine.. I am absolutely new to the iptables thing, so please be kind ;)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #53 from Mikko Korkalo mikko@korkalo.fi 2008-07-09 17:24:02 --- (In reply to comment #52)
So... DOES the above iptables rule work or is it just an idea?
There's no such thing unless someone writes one.
( Actually, it would be actually be better to use it in the OUTPUT chain instead of FORWARD chain, because OUTPUT can be used in the workstation itself, whereas FORWARD would need to be used in the router. )
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #54 from Daniel Santos daniel.santos@pobox.com 2008-07-10 02:11:16 --- Yes, the "filterdupes" is a proposed idea and has not yet been written.
After further testing using my proposed hack, I'm actually finding it to work significantly better than before, although there's still WAY too much traffic that does not consist of dupes. I did change WS_LOTRO_HACK_BUF_LEN to 0x80 (128) to reduce the CPU hit. Also, keep in mind that this is highly unrefined. For instance, the cache of packets should be sorted and then lookups should be able to use an index, btree or something and bail out as soon as a difference is discovered. I believe that memcmp will compare every byte, etc.
None the less, when playing two accounts (on the same box) in areas that used to be nearly impossible, I am still able to notice some minor ruberbanding, but nothing like it used to be. One area I can think of that's always been especially bad is in the Shire, east of Brudgeford near and in the wolf camp. When I revisited this place yesterday, it was dramatically different. This is good because it proves this will work and it also provides an immediate solution for those who don't mind altering their wine install :)
http://bugs.winehq.org/show_bug.cgi?id=12302
Thomas Benn sotis@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sotis@gmx.net
--- Comment #55 from Thomas Benn sotis@gmx.net 2008-07-10 02:29:52 --- (In reply to comment #54)
Yes, the "filterdupes" is a proposed idea and has not yet been written.
After further testing using my proposed hack, I'm actually finding it to work significantly better than before, although there's still WAY too much traffic that does not consist of dupes. I did change WS_LOTRO_HACK_BUF_LEN to 0x80 (128) to reduce the CPU hit. Also, keep in mind that this is highly unrefined.
How do I apply your code? Any helpers? :)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #56 from Daniel Santos daniel.santos@pobox.com 2008-07-10 09:01:23 --- (In reply to comment #55)
How do I apply your code? Any helpers? :)
Possibly the easiest way is to download the binary I compiled a few days ago here: http://codemonger.org/files/ws2_32.dll.so.bz2 but I don't promise it will work on your system (I'm running amd64 Gentoo). Also, I did change the buffer size, so that isn't the same as what I'm running now.
Otherwise, you'll need to compile wine. I would first make sure you can compile it successfully on your system (I'm sure there's a HOWTO on that somewhere). You should either pass WS_LOTRO_HACK_BUF_LEN=128 to the configure script or just edit the patch file and change "0x400" to "128". So your call to configure might look something like this:
CFLAGS="-O2 -pipe" CPPFLAGS="-DWS_LOTRO_HACK_BUF_LEN=128" ./configure
Next, copy socket.c.lotro_hack.patch into the root of the sources, change to that directory and run this run this command:
patch -p0 < socket.c.lotro_hack.patch
You should see no errors. Also, this patch is intended for wine v1.1.0. After patching, recompile (run make again). Then, assuming that didn't fail, figure out where ws2_32.dll.so is installed on your system, make a backup of it and then replace it with one that gets generated from your compile (it will be under dlls/ws2_32). Mine is under /usr/lib32/wine. Also, on 32 bit systems, it might not end with .so (might be .sl, but maybe I'm thinking of HPUX).
Daniel
http://bugs.winehq.org/show_bug.cgi?id=12302
Jörg Selbach sidolin@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|sidolin@gmx.net |
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #57 from Caladan a.vankaam@chello.nl 2008-07-10 10:57:24 --- I dont fancy a custom Wine, but will look into compiling this weekend, however this made me think of 2 things:
1- if this is a Lotro bug in the client could it be that the "orignal windows" dll or whatever handles this in windows does something similair to to reduce massive udp packages ?
2- I am still wondering why not everyone using Wine has this issue with lotro, could it be something in our linux network settings, ip6 or whatever that is diffrent ?
and finally who would be smart enough to make a filterdupes :)
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #58 from Andreas Blochberger andreas@blochberger.net 2008-07-10 12:17:37 --- This patch approach looks promising, but i would prefer a kind of runtime option to enable/disable this patch. This way it could be possible for this patch to make it into the official wine. Maybe some other applications are also suffering from this behaviour. Unfortunatly i cant help testing, because i dont have an account right now. But still, this issue only seems to affect european players
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #59 from Daniel Santos daniel.santos@pobox.com 2008-07-10 20:18:00 --- (In reply to comment #57)
I dont fancy a custom Wine
Me neither
1- if this is a Lotro bug in the client could it be that the "orignal windows" dll or whatever handles this in windows does something similair to to reduce massive udp packages ?
No. In fact, that is quite far beyond the bounds of a reasonable supposition.
2- I am still wondering why not everyone using Wine has this issue with lotro, could it be something in our linux network settings, ip6 or whatever that is diffrent ?
Here's a good quote from this thread on codemasters http://community.codemasters.com/forum/showthread.php?t=269211&page=2&am...
If you understand anything about programming in languages like C, C++, assembly, etc., you know that there are contracts with each interface you call. Take printf from the standard C library. You pass "%s" and a single pointer to a null-terminated character array and it prints your string. But if you pass "%s" followed by anything other than a pointer to a null-terminated character array then the results are (and a quote every C library specification for printf) "undefined". Undefined may mean that it prints nothing, prints the string "(null)" (which some implementations will do if it detects a null pointer), crashes your app, or if you are running windows it just may blue screen your ass.
and finally who would be smart enough to make a filterdupes :)
Just because you aren't smart enough doesn't mean that others aren't.
(In reply to comment #58)
This patch approach looks promising, but i would prefer a kind of runtime option to enable/disable this patch. This way it could be possible for this patch to make it into the official wine. Maybe some other applications are also suffering from this behaviour. Unfortunatly i cant help testing, because i dont have an account right now. But still, this issue only seems to affect european players
I live in the states and I have this problem, so this does not just affect European players.
From the discussions I've had in chat with a few of the wine devs, I very
seriously doubt they would accept such a work-around in the mainline. If they would accept it, then indeed it could easily be turned on and off by passing a parameter somewhere or setting an environment variable. Also, changing it in the wine dlls will have a significantly lower CPU hit (even though I don't think the hit will be all that big in netfilter). But I think those are all moot points.
I really don't mean to be a jerk, but I'm seeing a lot of "what if this happens all of the time" type of questions and I really don't want to respond to them all. Please refrain from asking questions and making suppositions that are far beyond your expertise -- attack green, blue and white mobs at will, yellow if you're well equipped and red if you feel lucky, but please leave the purples alone.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #60 from Daniel Santos daniel.santos@pobox.com 2008-07-11 17:05:33 --- I've been reading up on netfilter and it appears that the best way to do this now days is via the netfilter_queue (http://www.netfilter.org/projects/libnetfilter_queue/index.html) library and it can be done entirely in userspace! :) Of course, it will have to be run as root, but I like this better than mucking around in kernel space and require less peer-review and scrutiny. There is an example program in the utils directory of the source package and I've been playing with it a little thus far. There's not much documentation out for this and what is out there is mostly out of date :( but it's been a nice learning experience.
So in summary, this should supercede the need to call ipfilter and write a netfilter module. Instead, there will be a program that runs in user space as root that will kill the packets via the netfilter_queue API. Additionally, it should be possible to write this program so that it can have the switch user bit set and be executed by a non-super-user and have it effect only their network traffic since the netfilter_queue API supports filtering by the user or group of the app who created the packet. The only other problem I haven't figured out yet is how to make sure that it's friendly towards two instances running on the same machine, as the wine dll hack currently is, as I haven't yet discovered a way to filter by process ID of the app that created the traffic.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #61 from Daniel Santos daniel.santos@pobox.com 2008-07-14 11:01:02 --- I have run into problems using netfilter_queue and have posted this bug: https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=547 . I guess we'll have to look at trying to get this fix integrated into wine.
I propose some mechanism similar to this one:
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\Hacks\LOTRO] "Enabled"=dword:00000001 "PacketCacheDuration"=dword:00000055 (85) -- this is milliseconds "PacketCacheSize"=dword:00000100 "PortA"=dword:00002330 (9008) "PortB"=dword:0000232a (9002)
So first, we have a global like this (we can do it in the thread-local data too if there's a good reason to do so): BOOL lotro_hack_enabled;
And in DllMain when we do DLL_PROCESS_ATTACH, we look for HKEY_CURRENT_USER\Software\Wine\Hacks\LOTRO\Enabled and initialize lotro_hack_enabled to it's value, or false if it or any of it's parents are not present. This way, there is a minimal amount of instructions that need to be executed for those who do not have this hack turned on. Even if it is turned on, I've been tweaking out the hack so it's more efficient. I'll try to get something together over the next few days and I'll be contacting AJ (the maintainer) to see if we can work this in. Otherwise, we're looking at having to fix netfilter_queue or add a netfilter module as Mikko proposed -- I would just prefer to stay out of kernelspace if possible.
http://bugs.winehq.org/show_bug.cgi?id=12302
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14652|0 |1 is obsolete| |
--- Comment #62 from Daniel Santos daniel.santos@pobox.com 2008-07-15 20:08:15 --- Created an attachment (id=14831) --> (http://bugs.winehq.org/attachment.cgi?id=14831) Proposed patch for wine mainline to correct network problems (lag) in lotro client.
I took the previous mechanism, refined is slightly, moved settings (including and on/off setting) into the registry. Of note, I got rid of the check for port because it seems to change the destination port if it feels like it (like you block too much of their spam) and I moved the code into their own files (lotro_hack.c/h).
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #63 from Daniel Santos daniel.santos@pobox.com 2008-07-15 20:13:57 --- Also, I did my last testing with these settings:
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\Hacks\LOTRO] "Enabled"=dword:00000001 "PacketCacheDuration"=dword:00000014 "PacketCacheLength"=dword:00000100 "PacketMaxDupes"=dword:00000001
I'm only keeping copies of packets for 20 milliseconds now and only allowing two duplicates in that time frame before dropping additional ones. Also, when dupes do come after that, I sleep for 10 milliseconds, partially because I know it's just going to keep spamming, partially so the frame rate doesn't suffer a hang up when it's doing this. Now, even when it goes on a spamming spree, game play remains smooth.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #64 from Andreas Blochberger andreas@blochberger.net 2008-07-16 12:07:35 --- Would be interesting to see, if this has any impact on other applications. Is it possible to determine, if the running process is the Lotro-client? If so, a combination of hackEnabeldInRegistry && isLotroClient would make sure, that no other application might suffer from misbehaviour caused by this hack.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #65 from Daniel Santos daniel.santos@pobox.com 2008-07-16 12:24:11 --- I found a way to get this to work *without* modifying your wine install. I posted instructions here: http://community.codemasters.com/forum/showpost.php?p=4262757&postcount=...
(In reply to comment #64)
Would be interesting to see, if this has any impact on other applications. Is it possible to determine, if the running process is the Lotro-client? If so, a combination of hackEnabeldInRegistry && isLotroClient would make sure, that no other application might suffer from misbehaviour caused by this hack.
When the registry entry HKEY_CURRENT_USER\Software\Wine\Hacks\LOTRO\Enabled is either missing or zero, the impact is about 3 or 4 CPU instructions per call to WSASendTo, which is exceedingly minimal. If it's present and non-zero, it generally *shouldn't* have any impact on any reasonably well-written udp-based programs because there's generally no excuse for sending that many duplicate udp packets so close together. Doubles or tipples can sometimes be justified when you want to increase the likelihood that at least one of your datagrams reaches it's intended target without having to wait for the lack of an ACK from your target to decide you need to resend -- generally for data that is both time critical and important. I have employed this technique in the past when writing a UDP-based protocol, but it's most certainly the exception. At worst, this hack would prevent more than 2 of identical packets from being sent within a 20 millisecond time frame, but you can tweak those values in the registry (see above post on settings).
I can only see a few other very rare circumstances where so many dupes could be necessary (maybe when attempting countermeasures for a known bad link, that tends to drop packets -- very extreme)
But just set lotroclient.exe to be the only one to use it and then there's no problem. You can either do this with winecfg or merge this into your registry.
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\AppDefaults]
[HKEY_CURRENT_USER\Software\Wine\AppDefaults\lotroclient.exe] "Version"="win2k"
[HKEY_CURRENT_USER\Software\Wine\AppDefaults\lotroclient.exe\DllOverrides] "ws2_32"="native"
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #66 from Caladan a.vankaam@chello.nl 2008-07-16 13:00:25 --- somehow you lost me there.
enable/disable via registry makes sense, however
[HKEY_CURRENT_USER\Software\Wine\AppDefaults\lotroclient.exe\DllOverrides] "ws2_32"="native"
lost me, I asumed from your post it would be in the mainline of wine (when accepted), so what does the above mean or do ?
anyways hope it will get accepted, will you hear when/what build ?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #67 from Caladan a.vankaam@chello.nl 2008-07-16 13:36:52 --- sorry Daniel Santos, was mixing up your 2 posts.
I tested the ws2_32.dll as you posted it and although I see the package loss at the lag locations, there no longer is a lag assosiated with it, will test some more comming days
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #68 from Caladan a.vankaam@chello.nl 2008-07-16 13:54:46 --- okay some test indications:
- I did the install as you suggested on the codemaster forums, and as I posted above the results looked good, however I have an application which I still have not found a good linux alternative for and it gave me some errors on ws2_32.dll, and no that application had no special settings in the registry.
Anyways I placed the original ws2_32.dll back (2.4k) and placed yours in the lotro directory. registry settings still the same (using winxp as that seems to works better in window mode)
REGEDIT4
[HKEY_CURRENT_USER\Software\Wine\AppDefaults]
[HKEY_CURRENT_USER\Software\Wine\AppDefaults\lotroclient.exe] "Version"="winxp"
[HKEY_CURRENT_USER\Software\Wine\AppDefaults\lotroclient.exe\DllOverrides] "ws2_32"="native"
The results are identical, you see the package loss ingame but no more lag, well done :)
I would prefer it being build into wine but if that is not accepted I will stick with the ws2_32.dll in the lotro directory this not conflicting with other programs.
http://bugs.winehq.org/show_bug.cgi?id=12302
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14831|0 |1 is obsolete| |
--- Comment #69 from Daniel Santos daniel.santos@pobox.com 2008-07-16 15:52:46 --- Created an attachment (id=14856) --> (http://bugs.winehq.org/attachment.cgi?id=14856) WSASendTo not clearing last error on success
Well, well, it looks like I've discovered the real underlying cause and it was in wine, not in lotro. WSASendTo() was not doing WSASetLastError(0) to clear the "last error" upon success, although it was correctly returning zero. Most apps aren't going to bother calling WSAGetLastError() when a function says that it worked, but they are in lotro and believed it failed, so they just kept trying over and over and over and over and over and over again.
http://bugs.winehq.org/show_bug.cgi?id=12302
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #70 from Dan Kegel dank@kegel.com 2008-07-16 15:55:36 --- Good catch. Can you also write a conformance test that verifies that WSASendTo() calls WSASetLastError(0) on success on Windows?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #71 from Andreas Blochberger andreas@blochberger.net 2008-07-17 02:21:24 --- In the API documentation for WSAGetLastError (http://msdn.microsoft.com/en-us/library/ms898741.aspx) you can read the following: "The return value indicates the error code for this thread's last Windows Sockets operation that failed"
If WSASendTo returns 0, then it did not fail, so a call to WSAGetLastError would be undefined (returning the last error of the last function that really failed). But it may be, that the Windows function resets the last error. But by contract, it would not have to do so, or is not even allowed to do so. So, the error in the lotroclient would be, that it calls WSAGetLastError regardless of the result of the WSASendTo.
If the Windows function resets the last error on success, then of course the wine function should do this as well, although it would be wrong, according to the API documentation.
http://bugs.winehq.org/show_bug.cgi?id=12302
Florian Friedrich friedrich@hooster.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |friedrich@hooster.de
--- Comment #72 from Florian Friedrich friedrich@hooster.de 2008-07-17 04:34:35 --- (In reply to comment #71)
In the API documentation for WSAGetLastError (http://msdn.microsoft.com/en-us/library/ms898741.aspx) you can read the following: "The return value indicates the error code for this thread's last Windows Sockets operation that failed"
If WSASendTo returns 0, then it did not fail, so a call to WSAGetLastError would be undefined (returning the last error of the last function that really failed). But it may be, that the Windows function resets the last error. But by contract, it would not have to do so, or is not even allowed to do so. So, the error in the lotroclient would be, that it calls WSAGetLastError regardless of the result of the WSASendTo.
If the Windows function resets the last error on success, then of course the wine function should do this as well, although it would be wrong, according to the API documentation.
Well, your documentation is for Windows CE (look at the bottom of the page). Here is the documentation for Windows 95 to Windows Vista: http://msdn.microsoft.com/en-us/library/ms741580(VS.85).aspx
And there you can find the following sentences: "If a function call's return value indicates that error or other relevant data was returned in the error code, WSAGetLastError should be called immediately. This is necessary because some functions may reset the last extended error code to 0 if they succeed, overwriting the extended error code returned by a previously failed function."
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #73 from Andreas Blochberger andreas@blochberger.net 2008-07-17 05:01:43 --- Well, its the first Google found, but anyways, for all platforms, the behaviour is somewhat undefind, if no error code was returned. A call to WSAGetLastError should of course be imitiadly after a failed function, because some other function *might* reset the last error. Function can reset the last error on succes, but they don't have to. WSAGetLastError only return valid information, if a preceeding function failed. But thats academic. Wine has to behave just like Windows here.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #74 from Dan Kegel dank@kegel.com 2008-07-17 05:33:57 --- There's no reason to argue here. Simply add a conformance test to the patch that proves how Windows behaves. Should be about fifteen lines of code tops.
http://bugs.winehq.org/show_bug.cgi?id=12302
Constantin Bergemann cbergemann@gmxpro.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|cbergemann@gmxpro.de |
http://bugs.winehq.org/show_bug.cgi?id=12302
Daniel Santos daniel.santos@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14856|0 |1 is obsolete| |
--- Comment #75 from Daniel Santos daniel.santos@pobox.com 2008-07-17 14:07:59 --- Created an attachment (id=14876) --> (http://bugs.winehq.org/attachment.cgi?id=14876) Modified WSASendTo() to clear last error upon success, as seems to be the windows behavior.
(In reply to comment #74)
There's no reason to argue here. Simply add a conformance test to the patch that proves how Windows behaves. Should be about fifteen lines of code tops.
Sure, there's a reason, it's fun and you get a lot of exercise jumping to conclusions, flying off the handle, running around in circles and climbing all over each others' backs! Besides, it took me more than 15 lines of code to write the tests -- this gives me something else to argue about, w00t!! On top of THAT, I had to spend a few hours reading up on how wine conformance tests are done, analyzing it to make sure I understand it's reasons and that it uses a good design, followed by concluding that it doesn't in my usual pompous fashion. :)
Please let me know what else I screwed up and I'll fix it. :) Thanks!
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #76 from Dan Kegel dank@kegel.com 2008-07-17 14:59:27 --- Good show. Only thing you did wrong I can think of off the bat is you didn't run on windows before submitting to wine-patches. That's a must; if you don't have a windows machine (virtual will do), get somebody else to test for you.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #77 from Caladan a.vankaam@chello.nl 2008-07-18 07:47:01 --- just out of intrest, if I get this right then the following is what is going wrong with lotro:
lotro -> WSASendTo (sending an udp package) lotro -> WSASetLastError (checking to see if it went right, eventhough WSASendTo returned that all went right, waste of time/resources)
Situation some of us then seem to get is:
lotro -> WSASendTo fails from some reason and sets LastError. lotro -> WSASetLastError shows error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error
etc. etc. filling up our bandwidth until some unknown other function sets LastError to 0 and lotro see that and stops the udp burst ?
What I cant place in the above is how this can be so area specific, meaning I have no issue at position X in the game and take 2 steps east and there it goes, take 2 steps west and its fine again.
Oh well, as Dan said, nice catch, hope it gets approved, till then using the custom dll in lotro directory.
Have you tested your proposed fix Daniel ? same resuls or better even as your custom dll ?
Oh and Dan, should this not be in all ws2_32 functions ?
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #78 from Jörg Selbach sidolin@gmx.net 2008-07-18 13:42:52 --- Nice work, thanks! I've just tested your second patch, and it works for me. I did not test exceedingly, but i did not have any load spikes on my network monitor, while running around in an area where the game was unplayable without the patch.
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #79 from Andreas Blochberger andreas@blochberger.net 2008-07-21 01:34:26 --- Can anybody with the power, change the component to "winsock"?
http://bugs.winehq.org/show_bug.cgi?id=12302
Brian K brikeener@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winsock
--- Comment #80 from Brian K brikeener@gmail.com 2008-07-21 06:10:43 --- Changed component to winsock.
http://bugs.winehq.org/show_bug.cgi?id=12302
Sebastian Wagner space2k@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |space2k@web.de
--- Comment #81 from Sebastian Wagner space2k@web.de 2008-07-21 14:32:30 --- "Modified WSASendTo()" patch works for me (runnning Ubuntu 8.04.1). No more packetloss. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=12302
--- Comment #82 from Daniel Santos daniel.santos@pobox.com 2008-07-21 17:40:58 --- AJ has accepted my patch, commit here: http://source.winehq.org/git/wine.git/?a=commit;h=b54b282a4f89da3809ae0e166a... Does this mean the bug can be closed as fixed or does that have to wait for the new release?
(In reply to comment #77)
just out of intrest, if I get this right then the following is what is going wrong with lotro:
lotro -> WSASendTo (sending an udp package) lotro -> WSASetLastError (checking to see if it went right, eventhough WSASendTo returned that all went right, waste of time/resources)
Situation some of us then seem to get is:
lotro -> WSASendTo fails from some reason and sets LastError. lotro -> WSASetLastError shows error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error lotro -> WSASendTo resends and success lotro -> WSASetLastError returns the previous error
etc. etc. filling up our bandwidth until some unknown other function sets LastError to 0 and lotro see that and stops the udp burst ?
Replace WSASetLastError() with WSAGetLastError() because this is what the lotro executable actually calls and this is correct.
What I cant place in the above is how this can be so area specific, meaning I have no issue at position X in the game and take 2 steps east and there it goes, take 2 steps west and its fine again.
Pin-pointing stuff like this when you don't have the code can be pretty challenging. None the less, I'm pretty certain it's related to being in proximity to some world object or npc that requires a special function (in the code) to manage it, and this is where said function has the problem. Alternately, it may just be the order of calls being made given various world objects and/or special npcs (for instance, only happens when a mailbox is within 200m). Stuff like this can be tricky. Either way, it's exceedingly common to call WSARecvFrom and have it fail with WSAWOULDBLOCK (I think 1005 decimal, something like that), so the "wsa last error" is freqently non-zero.
But if you are depending upon the result of WSAGetLastError() when the docs for WSASendTo() don't tell you its set, you're asking for trouble.
Oh well, as Dan said, nice catch, hope it gets approved, till then using the custom dll in lotro directory.
Have you tested your proposed fix Daniel ? same resuls or better even as your custom dll ?
Oh and Dan, should this not be in all ws2_32 functions ?
Thanks! :) And it finally did get approved! I actually had problems with my own testing, when I ran dlls/ws2_32/tests/ws2_32_tests.exe.so sock on my linux box, I got a lot of failures (not from my patch though). I finally got to a windows xp laptop and got wine compiled for tests, but the tests still failed with one error (with and without my patch). I presume somebody else has tested and satisfied AJ, because I never got a zero failures build on windows :(
Also, performance using the WSASetLastError compared to my previous hack is much better, packet count and bandwidth is WAY less, because there were still non-identical packets that were spamming, just not as bad as the duplicates. What I notice most is when players are using /music, the notes appear to be arriving on time, whereas before, the notes were out of time.
http://bugs.winehq.org/show_bug.cgi?id=12302
Kai Blin kai.blin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #83 from Kai Blin kai.blin@gmail.com 2008-07-22 00:45:03 --- (In reply to comment #82)
Thanks! :) And it finally did get approved! I actually had problems with my own testing, when I ran dlls/ws2_32/tests/ws2_32_tests.exe.so sock on my linux box, I got a lot of failures (not from my patch though). I finally got to a windows xp laptop and got wine compiled for tests, but the tests still failed with one error (with and without my patch). I presume somebody else has tested and satisfied AJ, because I never got a zero failures build on windows :(
I'm aware there's one failure in the winsock tests on windows xp, but so far AJ didn't like any of my attempts to fix it.
Anyway, if the patch is accepted we can resolve the bug as fixed, AJ will close it after the next release.
http://bugs.winehq.org/show_bug.cgi?id=12302
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.0.1
--- Comment #84 from Alexandre Julliard julliard@winehq.org 2008-07-25 10:28:44 --- Nominating for 1.0.1.
http://bugs.winehq.org/show_bug.cgi?id=12302
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #85 from Alexandre Julliard julliard@winehq.org 2008-07-25 13:01:54 --- Closing bugs fixed in 1.1.2.
-
wine-bugs＠winehq.org