2,841 karma · joined November 20, 2012
juuso.dev
The problem is exactly what you described: there are currently no commercial UE or base stations. So yeah, I suppose one is supposed to use SDR for the 5Ghz band.
You can start your own telenetwork with these projects (but of course doing such would be highly illegal without a spectrum license), but first, you need a gNB or eNodeB which is lingo for a base station. It is possible to buy an SDR and use software like https://github.com/srsLTE/srsLTE to make the SDR receive and broadcast LTE/5G connections. After this, you need to have blank SIM cards to code. For example, this post instructs how to do so: https://cyberloginit.com/2018/05/03/build-a-lte-network-with.... You might also consider writing eSIMs https://github.com/bagyenda/njiwa.
After this, you should be able to use a commercial phone to connect to the network.
In general, these networks function quite well even on commodity hardware. Some tests I worked on produced end-to-end latency of around 20ms on LTE, and throughput of around 7MB/s. This was using NextEPC on a 400 euro computer with a 50 euro router and a Nokia base station. Further, it was possible to make the system to work in a Heroku like manner by exposing PaaS endpoints and running Kubernetes in the access network: https://www.semanticscholar.org/paper/Open-source-RANs-in-Pr...
I think it's quite likely that sooner or later we will have 5G networks with intra-services running as edge-services, providing us low-latency. It's worth noting that with the latest LTE versions 5G and LTE access latency is virtually the same. The real latency-optimization would be, at least to my perspective, to allow software to be deployed _into_ these cellular networks to minimize network hops.
Conversely, do know that this may not yield much appreciation from professors. BSc and MSc degree programs don't generally reward you for doing work that is so deep to be publishable. Even though you are at college to learn, you can't get carried away learning by yourself, if it is in the way of passing exams.
> What are the implications of identifying a scenario where there is no race condition?
No race condition? Great. It's totally possible there are some not-so-concurrent parts of your software that can run in what I deem a performant manner.
> Does it just result in a performance hit?
It's much more than that. A bug I have is very serious and it goes something like this: you set a limit order to buy X shares. The limit order gets a partial fulfillment, and you immediately set stop losses and take profits for X shares. However, the limit order gets complete fulfillment before the two other requests are done. If you now try to update the previous orders, for example, it might be that the update call gets registered at the broker first, but the creation gets there last, which means you have bought X+Y shares, but you have stop losses and take profits for only the X. You might now completely lose Y unless you monitor the software all the time. Things like these might happen everywhere, and the real trouble starts when these instances with plausible race conditions of their own start communicating with other parts which might also have race conditions.
And the requirement for the concurrency is not only a performance: you might want to collect data in thread N, while you have different strategies of amount M, which all by default subscribe to N, but only selectively when they are doing their strategies. In such a sense, I don't think that doing even a semi-serious trading software without concurrency is possible.
Alas, this supports SPIR-V to 1.1.
One question: in one of the slides, you mention the Vulkan 1.2 / SPIR-V 1.5 Vulkan Memory model. What exactly is this and why do you think this is meaningful? Would you have any links to learn more? When I read the SPIR-V specification, it mentions that this kind of memory model exists, but it does not put any effort into explaining why it's worthwhile or how it works on a high level.
Eventually, Spotify released its official mobile apps and a web player so the project had no use. But it was fun times, it was really marvelous how anyone could find their favorite music from the service and listen to them in good quality without a torrent connection.
Nowadays, I think all those friends who used the hack are Premium subscribers.
The same goes for work. Shit hits the fan during the day, and to offset the frustration I drink coffee.
It's the same for past-time. When I start slipping from my workout routine, a fast line of pure caffeine just before I should be going to the gym sets my mind on going to the gym.
And I don't take it lightly -- when the stress from expectations and accumulated responsibilities start appearing at the same time of the year (as they in some wicked way always do) I start piling on caffeine. Once I was even hospitalized.
Years ago in simpler times, I was able to take a week-long vacation in a forest cabin without electricity (or coffee). The first day I did not want to do anything, so I slept 20 hours instead, waking up occasionally for an hour or so before going to sleep again. This continued for the next two days, and the people accompanying me thought I fell sick. On the fourth day, I finally felt like actually doing something. I felt like a lot of the stress and crankiness was gone, and I became more open about helping others again. Yet, at the same time, this is exactly how I end up finding new responsibilities - worthy of the added concentration of caffeine - again.
An example in Finnish:
- jousta (normal form of the verb run)
- juoksen (I run)
- juoksentelen (I run around)
- juoksentelisinkohan (I wonder should I run around)
- juostaankohammekohaan (I wonder do we run)
The two later forms are very rarely used, and I have no idea whether the last form is even correct. I have some friends who insist on talking like this. Usually, people express the same things with more words, such as juoksentelisinkohan is equivalent to about:
- Mietin ., että. pitäisikö. minun. juosta. ympäriinsä.
- I wonder., that. should. my (in this context, me). run. around.
The . are to separate the words.
Yet, it would be perfectly fine to just append a question mark to juoksentelisinkohan or juostaankohammekohaan and it would be a one-word sentence. An interesting remark is that in practice the question mark is redundant in both cases, as the -ko- part in the words reduces the only interpretation of the word to be a question.
I have absolutely no idea how would one formalize all this.
In general, "how/if 5G is actually going to enable things like this in a way not possible with 4G" can be done. But, from a software engineering perspective, this has more to do with how the playing field is changing for mobile network operators than to the consumer.
I've met a lot of people (at work and post-grad) who have graduated from colleges without an idea of what a functional language is or the concepts behind them. I don't blame them, but its a pity to find so many workarounds in legacy code which could have benefited from functions as parameters and less state in general.