Trunk nightly

For test results, bug reports, announcements of new builds etc.

Moderators: another_commander, winston, Getafix

Post Reply
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 13821
Joined: Sat Jul 04, 2009 9:31 pm
Location: Corke's Drift
Contact:

Re: Trunk nightly

Post by Cody »

Norby wrote: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).

User avatar
Norby
---- E L I T E ----
---- E L I T E ----
Posts: 2560
Joined: Mon May 20, 2013 9:53 pm
Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
Contact:

Re: Trunk nightly

Post by 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.

User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 13821
Joined: Sat Jul 04, 2009 9:31 pm
Location: Corke's Drift
Contact:

Re: Trunk nightly

Post by 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.

User avatar
Norby
---- E L I T E ----
---- E L I T E ----
Posts: 2560
Joined: Mon May 20, 2013 9:53 pm
Location: Budapest, Hungary (Mainly Agricultural Democracy, TL10)
Contact:

Re: Trunk nightly

Post by 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 ;)).

User avatar
spara
---- E L I T E ----
---- E L I T E ----
Posts: 2555
Joined: Wed Aug 15, 2012 4:19 am
Location: Finland

Re: Trunk nightly

Post by 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.

Image

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Trunk nightly

Post by 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.

User avatar
spara
---- E L I T E ----
---- E L I T E ----
Posts: 2555
Joined: Wed Aug 15, 2012 4:19 am
Location: Finland

Re: Trunk nightly

Post by spara »

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

User avatar
StathisR
Dangerous
Dangerous
Posts: 71
Joined: Fri Jun 08, 2012 9:31 pm
Location: Serres, Greece

Re: Trunk nightly

Post by StathisR »

cim wrote:
UK_Eliter wrote: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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5526
Joined: Wed Feb 28, 2007 7:54 am

Re: Trunk nightly

Post by another_commander »

StathisR wrote: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.

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Trunk nightly

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5526
Joined: Wed Feb 28, 2007 7:54 am

Re: Trunk nightly

Post by another_commander »

cim wrote: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
Poor
Poor
Posts: 4
Joined: Mon Jun 16, 2014 7:39 pm

Re: Trunk nightly

Post by Typhon »

another_commander wrote:
StathisR wrote: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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5526
Joined: Wed Feb 28, 2007 7:54 am

Re: Trunk nightly

Post by 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.

User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 13821
Joined: Sat Jul 04, 2009 9:31 pm
Location: Corke's Drift
Contact:

Re: Trunk nightly

Post by Cody »

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

User avatar
StathisR
Dangerous
Dangerous
Posts: 71
Joined: Fri Jun 08, 2012 9:31 pm
Location: Serres, Greece

Re: Trunk nightly

Post by StathisR »

another_commander wrote: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.

Post Reply