wertigon |
Posted on 20-02-20, 14:35 in Semaphore timing issues in Linux (revision 1)
|
Post: #121 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
No, I want to take a lock OR wait three seconds, and if the lock is not successfully taken within these three seconds, exit the program with catastrophic failure. sem_timedwait() allows me to do this. So does pthread_muted_timedlock(). But pthread_cond_timedwait() always wait three seconds regardless if the lock is available, or not. And cond_timedwait() is the only way I can use CLOCK_MONOTONIC, instead of CLOCK_REALTIME. I wish to avoid CLOCK_REALTIME because it can be altered in this way:
The above code should print:
Now let us imagine a daylight savings time take place just as the code is run, you instead get
I want this code to be reliable, not prone to the settings of the REALTIME clock changing. |
wertigon |
Posted on 20-02-24, 08:22 in Semaphore timing issues in Linux (revision 2)
|
Post: #122 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Regarding timezones, that is one thing that might screw things up - another one is NTP, or PTP, or a whole slew of different timesync protocols. Not using timesync is unfortunately not an option for this application, we need it. Regarding pthread_cond_timedwait, yes, you are correct, after some testing and further research I've confirmed it too. So, to sum it up: does the same thing as
which does a completely different thing from
And both of the former calls support CLOCK_REALTIME and only CLOCK_REALTIME, while only the last call supports CLOCK_MONOTONIC (in addition to CLOCK_REALTIME). Why is there no pthread_mutex_timedlock_monotonic()? T_T It might be just me, but I strongly suspect this API come from the same guys that developed PHP... |
wertigon |
Posted on 20-02-28, 10:07 in Semaphore timing issues in Linux (revision 2)
|
Post: #123 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Ah, now I understand the problem. Consider the following code:
Now type this in terminal:
Why would this cause period instability, and how can I guarantee period stability? The answer is pretty obvious if you think about it. :) |
wertigon |
Posted on 20-03-02, 13:58 in Semaphore timing issues in Linux
|
Post: #124 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by funkyass Doesn't matter what time sync software I use, ntpdate was just an example. In theory, I should have a period of 100ms in the above code. In practice, if I get timesynced and add/remove +/- 50ms to the realtime clock every 500 ms, I will have timing periods like this (in ms): 100,100,100,130,100 100,100,100,80,100 100,100,100,60,100 100,100,100,120,100 100,100,100,150,100 This is not what I want. |
wertigon |
Posted on 20-03-02, 14:07 in Show us your Linux/BSD Desktop setup!
|
Post: #125 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by Maxane Eh, most of us perhaps change the wallpaper to something prettier. I went with i3 for a while and still miss it on occasion, I used emacs with evil back then too. Best multi-monitor setup I've ever used. These days I'm fairly content with stock Ubuntu on my single screen. :) |
wertigon |
Posted on 20-03-05, 08:17 in Semaphore timing issues in Linux (revision 1)
|
Post: #126 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Yes, I am aware of this. It is not a problem that a jitter happens or that it comes in a bit late, as long as it is within the period. The problem is that the period gets displaced by x ms every 500 ms, so in absolute numbers and in ideal conditions I would get these numbers: 100,200,300,400,500 600,700,800,900,1000 1100,1200,1300,1400,1500 1600,1700,1800,1900,2000 2100,2200,2300,2400,2500 With a monotonic clock and jitter introduced something like this might be more likely: 102,205,301,410,541 601,702,804,903,1002 1108,1207,1306,1418,1523 1608,1706,1810,1917,2033 2119,2202,2301,2412,2507 Still fine, no deadline misses, might want to do some slight tweaking though. But with REALTIME clock I get these "periods" instead: 102, 205, 301, 440, 571 631, 732, 834, 913, 1012 1118, 1217, 1316, 1388, 1493 1578, 1676, 1780, 1907, 2023 2109, 2192, 2291, 2452, 2547 Which, when compiled into bar charts, provide this kind of periodic accuracy: https://imgshare.io/image/timing-problems.t7tqY You should never be too early, yet clearly here we are... |
wertigon |
Posted on 20-03-13, 08:30 in Computer Security news
|
Post: #127 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by kode54 Only light in the tunnel is that this does not affect newer Intel CPUs at all, so you have four options pretty much: 1. Use mitigations and run at 20% efficiency 2. Run without mitigations and leave your system wide open 3. Pay Intel $$$$$$$$$$$ for new CPUs that are not compatible with your current sockets 4. Pay AMD $$$$$ for new CPUs that are not compatible with your current sockets Hmm, what is the best option here... |
wertigon |
Posted on 20-03-13, 09:18 in Semaphore timing issues in Linux
|
Post: #128 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by kode54 Depends on the loop. If you say "sleep 100 ms" at the end of the period, then yes, it will stack. If you say "sleep until time x" where x is the time the thread started plus y*100ms, where y is the number of iterations run, then no, it does not stack. Unless you tamper with the clock, which you do when running time sync protocols together with this concept. But that is clock changes stacking, not jitter. |
wertigon |
Posted on 20-03-16, 10:18 in Semaphore timing issues in Linux (revision 1)
|
Post: #129 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by funkyass It has soft realtime requirements, yes. Hard realtime no - then we'd use FreeRTOS instead (as we do on a few different products in the same family). |
wertigon |
Posted on 20-03-17, 07:25 in Computer Security news
|
Post: #130 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by creaothceann That is actually 1 or 2, depending on if you want the mitigations or not. |
wertigon |
Posted on 20-04-28, 08:03 in Computer Hardware News
|
Post: #131 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Speaking of hard drives; looks like soon you will need an NVMe drive to play latest AAA titles since SATA will be too slow in the newest consoles. On the plus side, the only things you will really have loading times for anymore is starting the game and non-graphics assets, since all graphics will be put on a built-in SSD in the GPU card. Imagine 256 GB GPU persistent memory with DDR2 equivalent IO speed... :) https://www.gamesradar.com/ssd-vs-hdd/ Only a decade left on the spinning rust and SATA ports, it seems! |
wertigon |
Posted on 20-05-23, 22:44 in higan v107 released
|
Post: #132 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
That's just... Plain awesome. I'm wondering if it would somehow be possible to implement the N64 GPU command set in Vulkan, in the same vein of DXVK. I think after Playstation 2 / Gamecube / Xbox, game devs got significantly less interested in squeezing every last drop of performance from the consoles, making LLE of such consoles much less interesting. Pretty much all of them after that are modern PCs in a cramped form factor, making emulation significantly easier. |
wertigon |
Posted on 20-05-24, 15:23 in COVID-19 (or why 2020 will SUCK for a lifetime) (revision 1)
|
Post: #133 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Actually, when it comes to the lockdown, the totalitarian measures as seen in most countries are pretty much throwing out the baby with the bathwater. What are the reasons for lockdowns? Two reasons, the first is to not overwhelm the healthcare system and storm the hospitals. The second reason is to develop better ways of treating patients. The goal here is to keep as few people as possible from dying, and the second reason makes less people die of this particular illness, while the former reason makes less people die of all illnesses. The lockdown does come at a cost though. The obvious one is the economy - every week noone is tending to the figurative wheat fields, the lesser the food stores for the winter will be. The less obvious cost is that most will still be susceptible to this virus, so if no cure or better enough treatment can be found soon, you would have traded a pointless massive economic damage for... What, exactly? The deaths will still happen, people will still get sick with cancer etc, but since they are in lockdown, a whole lot MORE will eventually die of starvation or sickness. It's impossible to say which strategy is best at the moment. The Swedish strategy is the "shield" strategy - it assumes most infected people will survive the virus, but some risk groups will not. Thus, you shield the elderly and weak, the ten percent of the population that would die for sure - and otherwise have measures in place to let the infection have a slow burn and not overwhelm the healthcare. Looking at the statistics, this assumption holds true. Most people who have died of the virus (at least 90%) are of 60 years age or above, and most regions are seeing a decline in the population. So the Swedish strategy has managed with the first point, not to overwhelm the healthcare system, really well. The high death numbers are partly because the most dangerous place to be in Sweden right now, is in the elderly care where many homes failed to take strong enough measures to shield the aging population. This is not an excuse, just plain facts. The Swedish strategy has therefore failed to keep the death counts low. Sweden is already coming out of their pandemic, while many other countries have yet to start on it, and Swedish measures will probably be copied for the exit strategies of many countries. That said, not all sunshine and roses. Every death is a failure, even if that death was pretty much unavoidable. |
wertigon |
Posted on 20-05-24, 15:47 in higan v107 released
|
Post: #134 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by CaptainJistuce Hardware wise, this is true. Software wise, you pretty much just use the provided APIs the firmware provides you after the PS2 era. That's what I mean with LLE not being as interesting with later consoles. |
wertigon |
Posted on 20-07-12, 08:28 in Computer Hardware News
|
Post: #135 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by tomman RIP Mac Master Race, the PC Master Race will avenge you! We would bring in our brethren from the Amiga Master Race as well except they went extinct since last time. |
wertigon |
Posted on 20-08-20, 15:26 in Where is the official download link for higan? (revision 1)
|
Post: #136 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Worth noting is that v115 is available, but only in source form. Or was that only bsnes/ares... hmmm... Building on Windows will probably be a pain, run Linux exclusively these days so I can't help you much. |
wertigon |
Posted on 20-08-26, 21:36 in Looking for a python script in the now defunct archives
|
Post: #137 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by MysticLord Would probably solve this with a one-liner bash script to be honest:
Works like this: * move csv file to stdin (cat) * Select the fields that are desired, and use comma as delimeter (cut) * Remove any commas and other unnecessary characters (sed s///g) * Optional: use > to save output to a text file |
wertigon |
Posted on 20-08-29, 14:08 in Looking for a python script in the now defunct archives
|
Post: #138 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Posted by MysticLord In that case:
Gives you the csv file as a Python list, then it's just a matter of looping over the list:
This is the inefficient but simple way to do it. Otherwise, do a text parser for it. :) |
wertigon |
Posted on 20-08-29, 14:18 in Misc. software
|
Post: #139 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Been diving into FreeCAD during the summer since my student license of SolidWork ran out, and I can't be arsed begging for a new one. It has been an interesting experience. To sum it up, I still think the premium on SolidWork is worth paying if you are working professionally with CAD, but if it's just for hobby purposes like me, then get FreeCAD. It is an awesome tool to learn, in some ways more capable than SolidWork, but bugs, unintuitive features and a general lack of consistent reworking tools keeps messing me up (e.g. try creating a model with 30+ features, then go back and change the base sketch to include a small pocket or something - ouch :() https://www.freecadweb.org/ |
wertigon |
Posted on 20-09-02, 21:00 in Computer Hardware News
|
Post: #140 of 205
Since: 11-24-18 Last post: 156 days Last view: 27 days |
Two quick bits of news: 1. Nvidia finally released some high end cards that are (kind-of) affordable for once, yay! (2080 Ti performance for $500 yes please!) 2. World of Warcraft will now require SSDs. Finally a reason to move from dog-slow HDDs other than loading times! :D Of course, sucks for everyone stuck on a mech, but... SSDs cost $30 bucks nowadays for a 256 GB option, so if you still haven't upgraded now is the time to do so. I wonder how long before SATA starts disappearing from new motherboards... |