| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Community
Forum: Chat Room
Thread: Okay, I confez, I'm not a Linux Adapt. |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 581
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Had an entertaining morning during upgrading to latest version of Kubuntu 16.04. System alerter said 16.04 was available and would I like to upgrade so said yes. At start the wonderfully optimistic download (and wrong) would take about 25 mins, that was wrong, it took an hour and half. With the download complete it asked if I wanted to proceed saying with dreadful pessimism (and wrong) that the upgrade would take 5 hours, lo and behold it only took 1hr and 35mins. Timing has possibly never brrn Canonicals best suit.
 Still got to work out how get my multi-function printer to connect. Happy days. |
||
|
|
KLiK
Master Cruncher Croatia Joined: Nov 13, 2006 Post Count: 3108 Status: Offline Project Badges: 
|
Hi guys,
----------------------------------------so after recently I've fried 2 nVidia GPUs 'cause of the "heat-sink fail"...decided that on GPU powered machines I have to run Tthrottle not to go it again...sadly, GT8500 & GT220 are as dead as a rock now, but will have some extra coolers if someone needs them?! So my desktops on Win also got their Tthrottle, like laptops did...put the Tjunc on 90% & let them crunch away! ;) But more importantly, GPUs only get to go 100°C...even though their Tjunc is so much higher (around 130°C)! On 2x linux machines I lack that program...& wouldn't want to fry another card by a simple heat-sink fail...so if anyone got some ideas & experiences with some program like Tthrottle which limits % of CPU on BOINC - especially on GPUs...I'd appreciate the input! thanks, ;) |
||
|
|
yoro42
Ace Cruncher United States Joined: Feb 19, 2011 Post Count: 8979 Status: Offline Project Badges: 
|
I've lost control of the following Four WUs due to Ubuntu 16.04 LTS Software failure. I reinstalled and WCG & Boinc Manager are running again. When I reinstalled I created a new "alongside" partition.
----------------------------------------I think the old files are still available but would they able to be reattached to the "new " partition and activated? If not please end and reassign? Still new to Linux, HST1_ 001037_ 000092_ AT0002_ T300_ F00092_ S00002_ 0-- Lester-Young Detached 4/24/16 04:04:13 4/24/16 07:55:14 0.00 / 0.00 0.0 / 0.0 HST1_ 001031_ 000076_ MT0004_ T300_ F00085_ S00001_ 1-- Lester-Young Detached 4/24/16 01:33:42 4/24/16 07:55:14 0.00 / 0.00 0.0 / 0.0 HST1_ 001031_ 000091_ MT0004_ T350_ F00094_ S00001_ 1-- Lester-Young Detached 4/24/16 01:33:42 4/24/16 07:55:14 0.00 / 0.00 0.0 / 0.0 HST1_ 001031_ 000088_ MT0004_ T350_ F00085_ S00001_ 0-- (Repost of [519892, HST1 Re: Detached WUs]  |
||
|
|
Falconet
Master Cruncher Portugal Joined: Mar 9, 2009 Post Count: 3315 Status: Offline Project Badges: 
|
yoro42,
----------------------------------------Those lost tasks will be reassigned if they haven't already. Seeing as it says "detached", you won't be able to run them again.  - AMD Ryzen 5 1600AF 6C/12T 3.2 GHz - 85W - AMD Ryzen 5 2500U 4C/8T 2.0 GHz - 28W - AMD Ryzen 7 7730U 8C/16T 3.0 GHz |
||
|
|
yoro42
Ace Cruncher United States Joined: Feb 19, 2011 Post Count: 8979 Status: Offline Project Badges:
|
Thanks Falconet. Pretty much as I expected.
----------------------------------------The new installed U16.04 is working fine with only WCG running. |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Something server operators may be interested in, bufferbloat, which is being fixed in kernel 4.7 but might get packports to earlier stable releases: http://phoronix.com/scan.php?page=news_item&px=May-2016-Bufferbloat
"Thus far this batch drop patch is testing out beautifully. Under a 900Mbit flood going into 100Mbit on the pcengines apu2, cpu usage for ksoftirqd now doesn't crack 10%, where before (under pie,pfifo,fq_codel,cake & the prior fq_codel) it went to 88% and ultimately bad things happened, like losing routability. I've had it running for hours and I hardly notice it's there. Performance for the normal cc controlled and/or sparse flows is unaffected, aside from the uncontrolled flows eating their percentage of the link. Nice work. Thx. This should go into -stable." |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Glad to be back home [not quite as the fridge had been thawing for over 3 weeks (main fuse went day 2 after departure) and needed mass clean out... was about to walk out the door, on it's own. Knew it on day 3, as the router did not show to be on-line :/]. In between the detox/decon launched the 14.04 > 16.04 Xerus upgrade, which comes with kernel 4.4.0.22-39 and read pieces of the change log, such as it saying amdgpu drivers from 4.5 were backported. https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Linux_kernel_4.4
Graphics and Display The upgrade prediction at start of several hours came true, but in that time BOINC kept running, service was several time auto-restarted due dependencies, and crunched on from last checkpoints [4 UGM are in progress]. After boot, all is running, launched good old synaptic for latest [none] and mail, web browser, file serving were spiffy as ever [what wonders, at most 2 minutes outtime to cycle the kernel and running smooth as ever... what a joy compared to ... most any other OS ;P)fglrx The fglrx driver is now deprecated in 16.04, and we recommend its open source alternatives (radeon and amdgpu). AMD put a lot of work into the drivers, and we backported kernel code from Linux 4.5 to provide a better experience. When upgrading to Ubuntu 16.04 from a previous release, both the fglrx driver and the xorg.conf will be removed, so that the system is set to use either the amdgpu driver or the radeon driver (depending on the available hardware). More information is available at https://tjaalton.wordpress.com/2016/03/11/no-...o-driver-in-ubuntu-16-04/ |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Installed Y PPA to fix the disabled repositories [upgrading does them all except Canonical's own] and re-name them proper in the list and decided to fast forward from the 4.4 stable to 4.5 stable kernel using the help off this instructional page: http://www.ubuntumaniac.com/2016/03/upgrade-linux-kernel-45-stable-on.html with highlights discussed at https://linux.slashdot.org/story/16/03/14/065...el-45-officially-released
Yakky Yak, or whatever other next 16.10 Ubuntu release of October is being fitted with 4.6, but word is it will either get the nearly finished 4.7 or even 4.8. At any rate, 3rd day running Xerus 16.04 LTS and stable as a rock this build is... greater than 99.5% efficiency on UGM. |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Kernel release 4.5 stable has been running 'stable' under 16.04 LTS, still 99+% efficiency in crunching UGM, so the next step will be putting hands on 4.6 stable, when it's out... June maybe. If it ain't work, can still choose at boot time for 4.4 or 4.5 or whatever kernels one wishes to keep on the system. Before going from 14.04 to 16.04 had about a dozen to pick from at boot time, default latest, never a reason to slip into a stroke of panic :D
----------------------------------------Crunch On. edit: A handy kernel archive page that lists what the latest stable is [4.5.4 at this time]: https://www.kernel.org/ [Edit 1 times, last edit by SekeRob* at May 12, 2016 8:34:00 AM] |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Ouch (Reminds me how I could not get CEP2 to do very well soon as running more than 1 at a time... running 1 was not tops either compared to Windows):
Is The Linux Kernel Scheduler Worse Than People Realize? Written by Michael Larabel in Linux Kernel on 16 April 2016 at 09:11 AM EDT. 86 Comments Emphasis mine.LINUX KERNEL -- A number of Phoronix readers have been pointing out material to indicate that the Linux kernel scheduler isn't as good as most people would assume. There is this paper entitled The Linux Scheduler: a Decade of Wasted Cores that covers the research done on the Linux kernel's scheduler to indicate it's suboptimal. Going along with that paper are these PDF slides further talking about how the Linux scheduler is doing a bad job and often overloading some CPU cores while leaving other CPU cores idle. The researchers were able to fix some of the scheduler bugs where there was a 23% performance improvement on a popular database with TPC or a shocking 137x performance improvement on HPC workloads. However, not at all of the scheduler issues can be easily addressed with simple patches but would require a more thorough redesign. The researchers concluded, "more research must be directed towards implementing an efficient and reliable scheduler for multicore architectures!" |
|||
|
||||
|
|