Trunk nightly

[Cody]

I am using the latest beta from nvidia.com...

Would that be the 340.43 beta, Norby? I've seen a couple of reports of 'oddities' with that version (I'm still using the 337.88 WHQL driver).

[Norby]

Thanks, but 337.19 is the last available beta for Linux. I tried the last non-beta (331.79) also but usually hangs up the whole machine after more hours of usage in random situations which seems to be fixed in the last beta.

[Cody]

Ah well, I know zilch about penguinista stuff - but when I had some trouble with nVidia drivers a while back, I reverted to an earlier trusted version (332.21) from the archive. Is there an nVidia driver archive for penguinistas too? Also, are you using the GeForce Experience thingy? I found that can cause problems.

[Norby]

I tried the oldest from the list also (325.15), but got the same random reboots after long and heavy usages (and sorry but I can not limit myself in the usage ).

[spara]

It looks like there is a minor bug in the hud code somewhere.

In the image below, the first one is from a mining trasporter with no missile pylons and the second one is from a cobra1 with one missile pylon. It seems that the drawMissileDisplay behaves differently in these cases.

[cim]

I can't duplicate this - I modified the Adder to have no missiles, and the ident display looked the same as the Cobra. It seems as if in the Mining Transporter screenshot weapons are offline, which would cause the drop in brightness.

[spara]

Oh my. You're right of course. It was the "weapons offline" at work there. Sorry about the false alarm.

[StathisR]

Well, only in a sense. The download numbers do change, but only very intermittently (once every minute or so); the rest of the time, nothing happens - hence (especially given the task manager behaviour) the appearance of a hang.

The way the Objective-C built-in downloader works, the download happens in a separate thread to the display. It looks like your system isn't giving the display thread enough time to run while the download's happening: maybe a problem with the OS, or the version of GNUstep we use on Windows, or something else. You have four processors - presumably they're mostly idle while this is going on?

Do the numbers at least jump up quite a few Mb when they do update?

Same thing here. I was trying to download a 103MB oxz file and the download number was freezing around 23MB and the program seemed to hang. In the last try i left it for five minutes and it completed the download although no change in the download numbers occured. The four cpu threads were not idle.I am running Win7 64bit and the latest trunk build ...-18c05dc.

[another_commander]

Same thing here. I was trying to download a 103MB oxz file and the download number was freezing around 23MB and the program seemed to hang. In the last try i left it for five minutes and it completed the download although no change in the download numbers occured. The four cpu threads were not idle.I am running Win7 64bit and the latest trunk build ...-18c05dc.

I think this issue is related to the connection speed. Am I right that all those who reported this problem have reasonably fast connections?

I tried this myself on a few different networks during my last business trip. At the hotel where I was lodging, the wireless network was exceptionally fast and I witnessed something similar to what StathisR describes. Then I moved to an airport's wireless, which was considerably slower, and the same ecact file (Random Hits Resources, 103MB) downloaded with almost normal update cycles (at the beginning updates were coming in rapidly, later on they started coming in after so many kb, but nothing that would look like a hang or similar). Then I tried it again at Amsterdam airport's wireless, which was somewhere in-between as far as speed goes and I had one instance only of a few seconds of "Not responding", with normal completion of the download.

I switched on debugging messages on the OXZ manager and I could see that whenever the game seemed to go in "Not responding" state, the packet size being read in was reported as 32768 bytes. The log was listing properly all incoming packets, although the update on the GUI screen was not always following suit. At the slower network, where updates were happening normally packet size was never above 28kb and the GUI screen was following the updates almost always correctly. In the blocking cases it looked as if incoming packets were coming so fast that the OS had no chance to allocate time to any other thread. CPU usage was showing not full utilization, but at least double to what it shows when Oolite runs normally.

I believe it may be either OS related or gnustep-base version related, as cim said. I am not sure there is a lot we can do about it at this stage, other than maybe try to test in various network speeds and see if there is a correlation indeed. Note that for various technical reasons, we cannot update the gnustep-base version on Windows.

[cim]

That makes sense. Downloading RHR from a webserver on the same machine had the packet size capping out at

Code: Select all

13:05:20.303 [oxz.manager.debug]: Downloaded 524288 bytes

here on Linux, which would mean that with a connection fast enough to throw that rate at it continuously, the file would be downloaded before the freeze in the GUI was noticed.

This seems to be to do with the BUFSIZ constant in stdio.h - the GNUStep connection buffer is always 64 times larger than that. On mine, that constant is 8192 - looks like on Windows it's 512. There doesn't appear to be any particular reason for this GNUStep behaviour, so we could possibly patch Source/NSURLProtocol.m in our Windows GNUStep build so that the lines which read

Code: Select all

unsigned char	buffer[BUFSIZ*64];

just said

Code: Select all

unsigned char	buffer[524288];

instead.

Not this close to a release, though - maybe we should add a warning to the downloader screen?

[another_commander]

Not this close to a release, though - maybe we should add a warning to the downloader screen?

Agreed. We can have this listed as a known issue and it will be the first thing I'll be looking at immediately after 1.80.

[Typhon]

Same thing here. I was trying to download a 103MB oxz file and the download number was freezing around 23MB and the program seemed to hang. In the last try i left it for five minutes and it completed the download although no change in the download numbers occured. The four cpu threads were not idle.I am running Win7 64bit and the latest trunk build ...-18c05dc.

I think this issue is related to the connection speed. Am I right that all those who reported this problem have reasonably fast connections?

Yes indeed. 80 Mbit/s Cable DSL here.

[another_commander]

For those with fast connections who may want to test, I have uploaded a 64-bit gnustep-base dll containing the change proposed by cim here: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

Does this make things better for you? Note, this is just for testing this particular issue only; 1.80 will not ship with this dll, even if reports show that it fixes the large files download apparent hang.

[Cody]

I doubt that my 20 Mb/s counts as 'fast' - but I can't do any testing atm anyway.

[StathisR]

For those with fast connections who may want to test, I have uploaded a 64-bit gnustep-base dll containing the change proposed by cim here: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

Does this make things better for you? Note, this is just for testing this particular issue only; 1.80 will not ship with this dll, even if reports show that it fixes the large files download apparent hang.

Unfortunately no improvement for me. My connection is 24 Mbit/s. I don't know if this is considered fast.