Pages: 1 2 3 4 5 6 7 8 9 10 11
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:


clock_gettime(CLOCK_REALTIME, &start);
clock_gettime(CLOCK_REALTIME, &timeout);
printf("%d HELLO\n",get_seconds_elapsed(timeout,start));
timeout.tv_sec += 1;
usleep(timeout);
clock_gettime(CLOCK_REALTIME, &timeout);
printf("%d WORLD\n",get_seconds_elapsed(timeout,start));


The above code should print:


0 HELLO
1 WORLD


Now let us imagine a daylight savings time take place just as the code is run, you instead get


0 HELLO
3601 WORLD


I want this code to be reliable, not prone to the settings of the REALTIME clock changing.
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:
pthread_mutex_timedlock()
does the same thing as
sem_timedwait()
which does a completely different thing from
pthread_cond_timedwait()


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


struct timespec next_wait;
clock_gettime(CLOCK_REALTIME, &next_wait);
int res;

while (1) {
next_wait.tv_nsec += 1000000; /* Wait one millisecond */
next_wait.tv_sec += next_wait.tv_nsec / 1000000000; /* Increase seconds if applicable */
next_wait.tv_nsec %= 1000000000; /* Reset nsec below 1B nsec */
if (pthread_mutex_timedlock(&sem, &next_wait) == 0) {
doSomeStuff();
pthread_cond_timedwait(&sem, &next_wait);
}
}


Now type this in terminal:

sudo ntpdate


Why would this cause period instability, and how can I guarantee period stability? The answer is pretty obvious if you think about it. :)
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
by not using outdated time syncing software? ntpdate was replaced with ntpd.


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.
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
I want to see some of of that riced desktops in action of what users have here!
Gonna want to do some inspiration for my transition of hobby use to full use.


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

It already does have a big performance impact, on the order of reducing performance to between 8 and 20% of the original performance. No, not reducing by that much, reducing it *to* that much:

https://www.phoronix.com/scan.php?page=article&item=lvi-attack-perf#=1


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...
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
Yes, jitter stacks. What, you thought they'd make up for it by returning to you *earlier* the next switch?


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.
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
Is all this running on a hard real time os?


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).
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
5. Use an older top-of-the-line CPU.

I'm still using my i7-4790K, which is €170 ($190) on ebay. It's comparable to a Ryzen 5 3600 in single-thread workloads.


That is actually 1 or 2, depending on if you want the mitigations or not.
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!
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.
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.
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
Playstation 3, XBox 360, and Wii are very unrelated to the IBM PC.
And squeezing performance was important to all three(especially the PS3).

Meanwhile, the XBox OG is closely related, but emulation efforts have long been halting steps stymied by lack of documentation of the VDP.


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.
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
Anyway, more bad news if you liked having a real GPU on your Mac: kiss goodbye your Radeons, as Apple is envisioning an "all-Apple" hardware strategy


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.
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.
Post: #137 of 205
Since: 11-24-18

Last post: 156 days
Last view: 27 days
Posted by MysticLord
Sorry for the double-post, feel free to merge it once someone notices me.

Could you find another script that xibalba e-begged off you all, which IIRC was something that would write concatenated text in a CSV to a file?

I think there were multiple versions posted, for C and Python (not sure which version of Python either). I'll take all of them, if possible.

Thank you once again.


Would probably solve this with a one-liner bash script to be honest:


cat test.csv | cut -f3,4 -d, | sed s/,//g > output.txt


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
Post: #138 of 205
Since: 11-24-18

Last post: 156 days
Last view: 27 days
Posted by MysticLord
While I appreciate your thoughtfulness and effort, my time is better spent picking up a little Python than beating my testicles with a hammer learning esoteric Windows command line tools.


In that case:


import csv

with open('file.csv', newline='') as f:
reader = csv.reader(f)
data = list(reader)


Gives you the csv file as a Python list, then it's just a matter of looping over the list:


for line in data:
output = ""
for index,field in enumerate(line, start=0):
output += field
if index < 2: # Keep the first two fields but remove , from the rest
output += ','

print(output)


This is the inefficient but simple way to do it. Otherwise, do a text parser for it. :)
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/
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...
Pages: 1 2 3 4 5 6 7 8 9 10 11
    Main » wertigon » List of posts
    Kawa's Github