| onefang | debdog: dan9er left so can't tag them. apt-panopticon is my baby, it monitors Devuan package mirrors, probing them in all sorts of ways. I do have a TODO item to add TOR support https://sledjhamr.org/mantisbt/view.php?id=78 | 02:50 |
|---|---|---|
| debdog | aight, I'll add this to my devuan link collection | 02:51 |
| debdog | (even though I have no clue what the site actually shows) | 02:52 |
| onefang | https://sledjhamr.org/apt-panopticon/results/Report-web.html http://veritas.devuan.org/apt-panopticon/results/Report-web.html https://ap.in.devuan.org/apt-panopticon/results/Report-web.html | 02:52 |
| onefang | https://mishka.snork.ca/apt-panopticon/results/Report-web.html is currently broken. | 02:53 |
| debdog | ohhhkay | 02:55 |
| debdog | same content? or do they differ somehow? sorry, very late here and I am pretty tired. and this is all about or, right? | 02:58 |
| onefang | The reason there's a bunch of them is to test the mirrors from different parts of the world. | 02:59 |
| debdog | hum, no. I don't get it, sorry | 02:59 |
| onefang | You should sleep on it. B-) | 02:59 |
| debdog | that prolly won't help either if I have no clue at all | 03:00 |
| onefang | And I should eat. | 03:00 |
| debdog | good ape tits! | 03:00 |
| onefang | lol | 03:01 |
| * golinux groans . . . | 03:03 | |
| Xenguy | Yes, we've officially reached the apex of lowbrow my friends = ) | 03:05 |
| Xenguy | (no pun intended) | 03:05 |
| debdog | hehe, SCNR. | 03:10 |
| debdog | ok, I've added these links now. still no clue whether I've understood that properly. pleas corrct me! (doing this to learn the wiki syntax as well as preparing a ossible wiki article: https://wiki.devuan.org/Main/KurtLiebhardt) | 03:11 |
| onefang | Did you actually look at them? Thought I had explained things plenty in the output web page. | 03:14 |
| debdog | well, not really, sorry. onefang. will do so tomorrow | 03:16 |
| debdog | they all have the same topic. and on a quick glance I wasn't able to spot any differences | 03:18 |
| onefang | Ah it's the differences you need explained. | 03:19 |
| onefang | The difference is in where they are located on the planet. | 03:19 |
| debdog | ahh | 03:20 |
| onefang | For example if there's some network issue in central Europe, then you'll see that in the sledjhamr output, but not on the mishka one. | 03:20 |
| bostanxhiu | Hello! I have installed tuxpaint from devuan repos, I opened it today for the first time in this machine, (tuxpaint default configuration, no changes by me), started playing a bit with it and after two or three minutes everything froze, Devuan included. Should I blame tuxpaint, devuan or both? | 19:27 |
| Besnik_b | (I did not see what nickname was used now, sorry…) | 19:29 |
| rwp | Besnik_b, If the system freezes then I would blame the Linux kernel. All of the software distributions use the same Linux kernel, pretty much, Red Hat patches aggressively making them different, and therefore if the system freezes I blame either the kernel or the hardware. | 19:36 |
| rwp | Some reasons the hardware might freeze are problems with the RAM. There is almost never ECC these days and therefore RAM errors can crash the system. I would definitely run memtest86 or memtest86+ overnight and test the RAM integrity. | 19:37 |
| rwp | If the system becomes overheated then Intel cpus will log that they are throttling and the system will run very slow. But good to check for overheating regardless. | 19:37 |
| Besnik_b | rwp, this is a new machine (128GB RAM) | 19:38 |
| rwp | Always browse /var/log/syslog the system log for anything interesting but honestly when I find a system is hanging there is almost never anything logged of note. | 19:38 |
| Besnik_b | AMD and a new liquid cooler | 19:38 |
| rwp | Large RAM systems such as 128GB can have RAM bus timing problems. That will take three days to run a full memtest across that much ram but it is probably worth it. ECC? | 19:38 |
| Besnik_b | Tuxpaint never froze in a 8GB machine before… | 19:39 |
| Besnik_b | No, not ECC | 19:39 |
| rwp | I really sincerely doubt it is tuxpaint. It probably could have been any program. It's just something that was running. | 19:39 |
| Besnik_b | I have 21 Firefox windows open, who knows how many tabs, and no troubles | 19:40 |
| rwp | With large RAM systems I have in the past had to do a divide and conquer approach to find which RAM DIMMs were causing problems. Pull out half the RAM. Run. Stable? Swap the RAM DIMMs to the other half. Stable? Repeat until finding the problem RAM DIMM. That's assuming the problem is a RAM problem. | 19:41 |
| Besnik_b | sensors reports +36.5°C | 19:41 |
| rwp | But with 128GB if you haven't been through the RAM in detail then that is often a finicky problem to get working reliably. | 19:41 |
| rwp | Besnik_b, The kernel should prevent any userland program from crashing the system. Full stop. It doesn't matter what program it might be. The system running is the responsibility of the kernel. User programs run under the kernel. Any misbehaving program might crash. But user programs should never be able to crash the kernel. Full stop. | 19:43 |
| rwp | If the system is crashing, hanging, freezing, then it is either the hardware flaking out or it is the kernel flaking out. | 19:43 |
| Besnik_b | In the previous machine I had 2x4GB RAM. Decided after some years to buy to more. Bought. And the troubles started. Never arrived at 16GB. Three modules, 8GB. Until two months ago, when I bought four identical new DIMMS and none of them worked, the machine eventually died and here I'm with the new one | 19:44 |
| rwp | Since you said you had 128GB of RAM and I know large amounts of RAM can require RAM memory cycle tuning honestly I immediately suspect that it is a hardware problem related to having a large amount of RAM and think that there probably needs to be another memory cycle or three added. | 19:45 |
| rwp | The system BIOS (which might not be BIOS on a new UEFI system now) might or might not have a RAM bus cycle tuning section that might help with figuring out the memory bus wait cycles. Some overclocking motherboards are very good for this. Others less so. I would boot to the boot firmware and look around and see if there is a RAM clocking section. | 19:47 |
| rwp | And otherwise I would simply try to reproduce the problem reliably. There is a program "stress" which can be used to apply load to the system. I would crank up stress and put the system through a burn-in series until I was confident in it. | 19:48 |
| rwp | https://packages.debian.org/bookworm/stress | 19:49 |
| rwp | I link to the Debian site but it is exactly the same package in Devuan. Since Devuan is operating as an overlay on top of Debian. | 19:49 |
| rwp | That's all I can recommend at the moment. I'll let others jump in with further help. | 19:50 |
| Besnik_b | rwp, thank you! | 19:54 |
| onefang | rwp: This tuning for large amounts of RAM thing you mentioned, got any useful links on that please? I have 256 GB in my desktop computer. Wish I could have got ECC for it, but that wasn't possible at the time. | 21:13 |
| rwp | onefang, If it has been working reliably for you then you should not need to do anything more. It's only if there are problems. Sorry but I don't have any references. | 21:15 |
| onefang | I do get odd segfaults, if I do certain things, which I think is RAM related. They go away when I reboot. Alas one of those things is "wait a month" so it's hard to reproduce quickly to see if I fixed it. | 21:15 |
| rwp | Fire up "stress" and really hammer on your system and see if you can break it. :-) | 21:15 |
| rwp | I have multiple times seen large ram systems assembled and it won't be stable. The problem is that adding ram adds capacitance to the ram bus creating an electrical R-C slowdown. The system can wait a little longer and allow the singles to be more solidly 1 or 0 before reading the value. Larger ram systems are always slower memory cycles than smaller ram systems due to this. | 21:16 |
| onefang | That's a "It's no longer weekend anywhere in the world, and Australia has run out of holidays, can't even blame my birthday anymore" job for Tuesday. B-) | 21:17 |
| rwp | s/singles/signals/ | 21:17 |
| onefang | Breaking it is easy, the hard part is figuring out which part out of my enormous amount of parts is the one that breaks? | 21:18 |
| onefang | If it's RAM, I hope I can just map out that particular page or whatever on boot, then forget about it. I can spare some RAM. B-) | 21:19 |
| rwp | Same thing happens with the cpu bus too. Just recently someone here or another irc channel asked why the dual core cpus often have a faster max clock rate than the quad core cpu. Same reason. More capacitance on the bus. | 21:19 |
| onefang | 64 cores. B-) | 21:19 |
| rwp | Sounds like you have a fun machine! :-) | 21:20 |
| onefang | I over specced it last time I had to rebuild my desktop. Should last a while before bloat catches up to it. | 21:20 |
| rwp | As machines get bigger the problem of reproducing problems become bigger. And more time consuming. It's a PITA for certain! | 21:20 |
| rwp | I found this reference on a site that I might trust to have correct information on it: https://www.intel.com/content/www/us/en/gaming/resources/overclock-ram.html | 21:22 |
| onefang | Ah I did have stress installed, so I likely tried it out before. | 21:23 |
| onefang | It's Saturday, and yesterday was a public holiday, but now you got me stressing about stress. ;-P | 21:23 |
| onefang | Stress, stress-ng, stressant, stressapptest, and those are just the easy ones to find. | 21:25 |
| * rwp achievement unlocked :-) | 21:25 | |
| * onefang adds Yet Another TODO for next week. | 21:26 | |
| onefang | Not sure how useful an Intel page would be on my AMD CPU, but I'll read that anyway. | 21:27 |
| rwp | RAM is a generic component these days following standards like DDR4 making the design the same for everyone. | 21:28 |
| rwp | But you asked so: https://community.amd.com/t5/pc-building-how-to-articles/how-to-configure-and-overclock-your-ram-in-the-bios-of-your/ta-p/594203 | 21:29 |
| rwp | Just anecdotally a friend bought a big memory system with either 256GB or 512GB of ram and after he finished doing extensive burn-in testing he determined he had 1 16GB RAM DIMM from the entire collection that was "soft" and susceptible to bit flips from row hammering and other testing of it. He got the vendor to swap him out that one RAM DIMM for another and then he decided his system was good to go. | 21:33 |
| onefang | "may also increase the power consumption and temperature of your memory kit." It's supposed to get to 37 C today, definitely something for later. | 21:34 |
| rwp | I doubt he would ever have had an actual problem with it. Probably would never have noticed if he had not specifically tested for it. And it took him days and days of runtime to conclude to that analysis. | 21:34 |
| rwp | May increase power consumption? Sure. Each clock cycle dumps charge through the circuit. If you increase speed then you get more cycles and therefore more power consumption. | 21:35 |
| onefang | Yes, I did the same. LEt the box sit and stem in memtest86 for days when I built it. Which found out the motherboard was faulty, after days if re arranging my RAM to see if I could nail down which stick. Replacement motherboard worked fine. | 21:35 |
| rwp | It's like a piston engine. Increase the rpm and you get more cycles of burning and therefore more heat. Increase the throttle manifold pressure and you get more fuel-air burned and therefore more heat. | 21:35 |
| onefang | It was the increase in temperature on a 37 C day I was complaining about. lol | 21:36 |
| rwp | It's winter here and after a couple of weeks of sub freezing we are having a heat wave today at 45F / 7C today. I am looking forward to summer now. | 21:37 |
| onefang | Stress testing will kick up the temperature to. Don't want AC on one side of me and heater on the other side, not today. | 21:37 |
| onefang | Summer here, already the second heatwave of the year. First one was for my birthday. lol | 21:38 |
| rwp | Manufacturers will usually rate their products to a certain ambient temperature and altitude too. I remember HP back in the day would usually rate their equipment to I forget what temperature but I remember it was 15,000 feet MSL altitude. Higher altitude is thinner air and heat sinks do not work as well. And the military would buy equipment and fly it in aircraft to high altitudes. So there had to be a spec for it. | 21:39 |
| onefang | I used to work for a computer builder in the tropics. We would pack them with a blanket and run them hard for 24 hours, before shipping them out to mine sites. | 21:40 |
| onefang | Back in the days when I would build those computers using a soldering iron. No board swapsies back then like I do now. | 21:41 |
| onefang | Buuuut.... oooofff topic. | 21:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!