But threads are more performant! Yes, but no. Why? Because it uses less CPU and it’s more efficient. I purposefully removed the threading ability and instead used a non-blocking approach.
Wrong! In fact the first library I found was internally creating threads all over the place, so I looked at the sources and coded something similar myself but single-threaded. Most people I talked about zzping they said that I surely used threads for the pinger. I’ve continued working in 0.2 in a beta branch. Up to this point it’s what I released as 0.1 in the main branch.
It can only show one host at a time, and if restarted it loses the history. This is what it looks like when displaying real-time data: But I saw that it was fast enough and I moved on. It’s possible that Iced is not optimized enough for this kind of stuff, or maybe (surely) I’m missing optimizations and caching.
#Blog ping tool drivers
But after profiling, this seems to come from my own NVidia drivers drawing, therefore on the Vulkan side of things. Still it takes “too much” time to draw, to the point that I found it deceiving I thought that would be faster. So I coded zzping-gui in Rust, and receiving the UDP events from the daemon, I could paint in real-time the ping timings and packet loss up to 10,000 lines in screen. But, as they quickly pointed out, Iced can paint into a Canvas quite well and that should do. Turns out that, obviously, there’s no GUI aside of FFI to GTK that is capable of graphing. So I went to Rust Discord servers to ask for advice on a Rust GUI library for this.
#Blog ping tool trial
But after some trial and error, realized that Qt charting libraries were mostly for office use, like 100 points or static viewing.Īs I wanted something that was able to display > 1000 points changing in real time, Qt was out of the question, and with this, Python was also out of the question as well. My idea was that Python could handle well enough the data size and Qt would be better than any Rust GUI. I thought that Rust would not have mature enough GUI libraries, so I played a bit with Python+Qt5.
The only relationship between this project and Google is the fact that I was working on it while being employed by Google) (Just note that even if Google is in the license, this is just a result of the review process. This is a tool that features a daemon pinger that will ping a configured set of hosts at roughly 50 pings per second, store the data on disk and also sends it via UDP to a GUI.Īfter 1-2 weeks of waiting for approval from my employer to release this, I pushed the changes into my github: So I thought that this is a good idea for a new Rust project.Īnd this is how zzping was born. It was hard to believe that there wasn’t any open source tool for this. I searched for other ping tools that better suit this purpose, but what I found was basically paid stuff. But the thing is, regular ping tools show more or less normal behavior, and to catch any packet loss I need a really aggressive ping that actually is really hard to see. For example, video calls tend to break up often, on-line games display random spikes of lag.īecause of this, I have been looking to ping my router and diagnose the problem. I get some disconnections or weird behavior in anything that requires a real-time connection over the internet. In the meantime, during this WFH period, I noticed that my home network is kinda strange.
#Blog ping tool code
And now I’m reaching a point where I see that Rust can actually be almost as fast to code as Python (there are still a lot of rough edges though). Played with several exercises and different things to get comfortable with it. After almost a year seems I got some energy back to start writing and doing some other stuff. To be sincere, these quarantines have ostracized me and haven’t keep up with almost anything, like hibernating waiting for this thing to go away. A lot of time has passed since my last post.
0 kommentar(er)
