Certainly the best thing that can realistically be done atm. We have seen now that the graphics are likely to cause serious trouble with the current application, so it's not a sensible idea for anyone to use them, and it would be terribly unrealistic to expect a fix in the next time, especially with the pressure the project already had. Besides, as Bernd already mentioned, most Linux users don't run the graphics anyway, so it won't be that much of a problem for the majority... I also like the idea to offer graphics for some systems which are known to be stable.
I also agree that an optional gfx package would be best. The graphics are real nice to visualize what the E@H client is doing and how the search is working in principle, but later on you don't activate it very frequently anyway.
My current WU is performing as usual. I'll do some more tests to make sure the effect was indeed graphics related (after all, it could also be a random thing that happens with a certain probability whenever you (re)start the app).
========
Note that the checkpointing appears to happen at regular time intervals (once per minute, I guess), so the speed of the processing is approx. halved after the event.
Hope this helps!! No wonder it didn't happen with my Intel, where the X session was not closed during the run.
I've been interpreting mine as the 'c' is the checkpoint, and the numbers are a timer tick between them.
This would indicate processing speed roughly doubled after the event. IOW, half as many ticks between c's.
Alinator
I'm quite sure about this. You can check for yourself when you do a tail -f stderr.txt in the right slot directory under the BOINC directory. The "c" is output every minute or so, the numbers represent sky-positions. At the head of the debug output there will be a line like "Total number of skypositions: xxxxx". The output goes then on to track the progress by counting 1,2,3 .... until this number xxxx is reached. So the "c" marks the timer event and the numbers represent a step in the computation (also if you have the "screensaver" open, the crosshair will move to a new position in the sky whenever a number is written to the stderr.txt.
After looking at a full stderr file I see you are correct. Each number is a 'skypoint' completed, therefore the more of them between c's (standard checkpoints and assuming they are at constant CPU time intervals) the faster the app is running.
Thanks for making me go back and really look at what I was seeing. ;-)
Each number is a 'skypoint' completed, therefore the more of them between c's (standard checkpoints and assuming they are at constant CPU time intervals) the faster the app is running.
Actually I think the "c" happens at constant real time intervalls, not CPU time. Put some load on your machine and you will see the number of skypos between "c"s decreasing.
Agreed, good point. I was basing that on what I was seeing in the stderr file only.
I'll give that a try by loading the host with something else to do, but I suspect you're correct there as well.
Alinator
After thinking about this a little more, the good news is;
Yes, the apps do in fact work the same on different platforms. The messages you get out of them may be a little different, but they are telling you basically the same thing. :-)
Just uploaded my second result. This one took about 3% longer than with the 4.21 app :-) so, looks like it's a go on my machine with the new app as long as I keep my hands off the grapics.
4.21 has (finally...) been made "official", thanks for help with testing it.
The slowdown from the graphics thread isn't nice, and I'll keep looking into the issue. But slowing down the calculation is much, much better than crashing, and in this sense this App is a lot better than the previous 4.18. Also too I'm more worried about the thousands of Linux installations that run unattended than about some people that play with the graphics, even more as the graphics slowdown problem seems to be limited to certain configurations (probably graphics library versions) - I've not noticed it on "my" machines, and Ziegenmelker apparently didn't on his, too (right?).
It looks like I need to convince some other E@H folks of my "optional graphics App" idea first, so a default non-graphical App might take a bit.
Certainly the best thing that
)
Certainly the best thing that can realistically be done atm. We have seen now that the graphics are likely to cause serious trouble with the current application, so it's not a sensible idea for anyone to use them, and it would be terribly unrealistic to expect a fix in the next time, especially with the pressure the project already had. Besides, as Bernd already mentioned, most Linux users don't run the graphics anyway, so it won't be that much of a problem for the majority... I also like the idea to offer graphics for some systems which are known to be stable.
Hi! So the result for the
)
Hi!
So the result for the mysteriously slow beta run is uploaded now:
http://einsteinathome.org/task/84075965
I also agree that an optional gfx package would be best. The graphics are real nice to visualize what the E@H client is doing and how the search is working in principle, but later on you don't activate it very frequently anyway.
My current WU is performing as usual. I'll do some more tests to make sure the effect was indeed graphics related (after all, it could also be a random thing that happens with a certain probability whenever you (re)start the app).
CU
BRM
P.S.: OK, I think I found
)
P.S.:
OK, I think I found what caused this slow down for me:
As I said, I opened the "screensaver", closed it again, and at that point everyhing must have worked fine.
Later on the VNC connection was closed and even tho the graphics windows was closed by then, this must have caused the slow-down.
Note the following extract from the stderr.txt (saved it locally before the result was updated):
========
1840, 1841, 1842, 1843, 1844, 1845, 1846, 1847, 1848, 1849, 1850, 1851, 1852, 1853, 1854, 1855, 1856, 1857, 1858, 1859, 1860, 1861, 1862, 1863, 1864, 1865, c
1866, 1867, 1868, 1869, 1870, 1871, 1872, 1873, 1874, 1875, 1876, 1877, 1878, 1879, 1880, 1881, 1882, 1883, 1884, 1885, 1886, 1887, 1888, 1889, c
1890, 1891, 1892, 1893, 1894, 1895, 1896, 1897, 1898, 1899, 1900, 1901, 1902, 1903, 1904, 1905, 1906, 1907, 1908, 1909, 1910, 1911, 1912, 1913, c
1914, 1915, X connection to :4.0 broken (explicit kill or server shutdown).
c
1916, 1917, 1918, 1919, 1920, 1921, 1922, 1923, 1924, 1925, 1926, 1927, 1928, 1929, c
1930, 1931, 1932, 1933, 1934, 1935, 1936, 1937, 1938, 1939, 1940, 1941, 1942, 1943, c
1944, 1945, 1946, 1947, 1948, 1949, 1950, 1951, 1952, 1953, 1954, 1955, 1956, 1957, 1958, c
1959, 1960, 1961, 1962, 1963, 1964, 1965, 1966, 1967, 1968, 1969, 1970, 1971, 1972, 1973, 1974, c
1975, 1976, 1977, 1978, 1979, 1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988, 1989, c
1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, c
2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, c
========
Note that the checkpointing appears to happen at regular time intervals (once per minute, I guess), so the speed of the processing is approx. halved after the event.
Hope this helps!! No wonder it didn't happen with my Intel, where the X session was not closed during the run.
CU
H-B
Hmmmm, are you sure you said
)
Hmmmm, are you sure you said that right?
I've been interpreting mine as the 'c' is the checkpoint, and the numbers are a timer tick between them.
This would indicate processing speed roughly doubled after the event. IOW, half as many ticks between c's.
Alinator
RE: Hmmmm, are you sure you
)
I'm quite sure about this. You can check for yourself when you do a tail -f stderr.txt in the right slot directory under the BOINC directory. The "c" is output every minute or so, the numbers represent sky-positions. At the head of the debug output there will be a line like "Total number of skypositions: xxxxx". The output goes then on to track the progress by counting 1,2,3 .... until this number xxxx is reached. So the "c" marks the timer event and the numbers represent a step in the computation (also if you have the "screensaver" open, the crosshair will move to a new position in the sky whenever a number is written to the stderr.txt.
CU
BRM
Ahhhhh.... After looking
)
Ahhhhh....
After looking at a full stderr file I see you are correct. Each number is a 'skypoint' completed, therefore the more of them between c's (standard checkpoints and assuming they are at constant CPU time intervals) the faster the app is running.
Thanks for making me go back and really look at what I was seeing. ;-)
Alinator
Hi! You're welcome
)
Hi!
You're welcome .
Actually I think the "c" happens at constant real time intervalls, not CPU time. Put some load on your machine and you will see the number of skypos between "c"s decreasing.
CU
BRM
Agreed, good point. I was
)
Agreed, good point. I was basing that on what I was seeing in the stderr file only.
I'll give that a try by loading the host with something else to do, but I suspect you're correct there as well.
Alinator
After thinking about this a little more, the good news is;
Yes, the apps do in fact work the same on different platforms. The messages you get out of them may be a little different, but they are telling you basically the same thing. :-)
Just uploaded my second
)
Just uploaded my second result. This one took about 3% longer than with the 4.21 app :-) so, looks like it's a go on my machine with the new app as long as I keep my hands off the grapics.
4.21 has (finally...) been
)
4.21 has (finally...) been made "official", thanks for help with testing it.
The slowdown from the graphics thread isn't nice, and I'll keep looking into the issue. But slowing down the calculation is much, much better than crashing, and in this sense this App is a lot better than the previous 4.18. Also too I'm more worried about the thousands of Linux installations that run unattended than about some people that play with the graphics, even more as the graphics slowdown problem seems to be limited to certain configurations (probably graphics library versions) - I've not noticed it on "my" machines, and Ziegenmelker apparently didn't on his, too (right?).
It looks like I need to convince some other E@H folks of my "optional graphics App" idea first, so a default non-graphical App might take a bit.
BM
BM