So I have an affection for Discord...so I appreciate posts like this.
>"Using the WebRTC native library allows us to use a lower level API from WebRTC (webrtc::Call) to create both send stream and receive stream."
So I'm gathering that discord's voice servers receive multiple persistent connections, then compress the audio streams for delivery to each end user. THIS part is where I can't imagine the on-the-fly cpu usage. Each client's receiving compression needs to also negate their own audio to prevent an echo effect (no point to hear your own voice), but it also means separate compression streams per user.
>" All the voice channels within a guild are assigned to the same Discord Voice server."
I imagine this helps significantly with I/O in converting live streams into 1 stream per end user. I've dealt with video compression (only in ffmpeg) and live syncing time stampings, and I can say from experience that, this is no easy feature. I understand this is audio streams (so lower overhead), but still the persistent voice server needs to handle the incoming connections, web socket heartbeats (negligible), compression (high I/O), and deliver the streams (high memory usage too).
I'm impressed, but would love to hear the specs on the media servers and their DL/UL speeds. My old setup to deliver live video (in sync and compressed) was 6 mini-itx's, 4GB of ram per board, and i3's...my bottleneck was my isp, which I solved with multiple docsis modems and an internal switch (each board had 2 ethernet ports).
We don't transcode audio/video on the server. Each stream is processed and muxed by the client. The server is merely relaying rtp packets and tagging them with a given ssrc per peer. The client does the rest of the work.
The bulk of the user-space time on the SFU is spent doing encryption (xalsa/dtls). We also avoid memory allocations in the hot paths, using fixed-size ring buffers as much as possible.
If Discord is basically proxying the raw packets from one client to the others, isn't that wasted bandwidth (for discord, not the clients). I understand from the post that the goal would be to mask the ip of the users, to shoulder user privacy and the ddos vector. Kudos on silence detection to save overhead.
So video w/audio broadcasting has to be compressed client side, then proxied through Discord's media servers, to the end user's. That's pretty smart...I just wished that I could send my raw stream to a LAN host so I could offload the compression, and allow my LAN host to provide delivery (I'm a nitro user).
Would rather waste bandwidth than CPU cycles in this case. Would take way too much CPU time to mux audio streams together server-side, and then recompress. (Means we have to buffer data for each sender, deal with silence, deal with retransmits and packet drops, have a jitter buffer, etc...). No way we'd be able to hit the # of clients we want per core with that overhead. Our SFU's are intentionally very dumb for this reason.
Also, muxing server side means we can't do things like per-peer volume and muting, without having to individually mux and re-encode for each user in the channel depending on who they have muted and the volumes they have set per peer (which would explode CPU complexity even further).
So, in this case, bandwidth is cheap, let's use (and waste) some, in an effort to simplify the SFU, and also, make it more CPU efficient. Default audio stream is 64kbps (or 8 KB/sec), per speaking user.
>"The overall goal: to ensure at least 100,000,000 Americans had access to broadband speeds of 100 Mbps by 2020. As it turned out, providers blew past that milestone as early as 2016."
First gripe....why oh why could they not make that goal for a symmetrical 100Mbps and not just focused on the DL speed.
If the push is to 5G, I'd welcome it, if the mobile carriers opened ports on consumer plans. I've cherished my coveted unlimited iPad data plan with att used in my mifi with a yagi that points right at the service tower. It regularly sees over 250Gigs a month (check my twitter for that pic).
As a coder, the only real drug I’ve ever really needed has been caffeine. This didn’t start until recently so I’m not sure if I can attribute it to age (early 30’s). My real dependence on caffeine is mainly due to staying up too late the night before (like right now, about 0200 here) and needing to get up and function with 5hrs of sleep and maintain my mental acuity for the workload I have.
To give you an idea of my caffeine intake...about 2 venti black coffees and an 8oz Red Bull.
I find that acidic juices such as Orange or Ananas juice cleans out most of the gunk that builds up overnight and gives you a short boost through the sugar in them. The sugar can usually cover until the coffee after begins to work so you don't get that period of slouch after drinking coffee before it works (drinking something warm tends to make drowsy too so you possibly get more tired after drinking coffee). Skipping/preventing this short moment of weakness improves on the day a lot.
Not to my knowledge, the acidity of the juice helps a lot to get more awake very quickly, pure sugar itself doesn't help that much to get the continous effect.
You may know this, but you're kidding yourself if you think your mental acuity is anything near optimal on 5 hrs of sleep. I don't care what you're drinking.
It takes about an hour before I can start churning clean code and start any code reviews, so I think I’m ok. Really, it’s the 3 in the afternoon feeling that is the drain for me. Alertness fades and I can’t even listen to music without an occasional syntax error.
You're kidding yourself if you think every human has the same sleep needs. For me 5 to 7 hours is optimal, 8 hours or more leaves me sluggish for the day.
If I'm working from home all I need is caffeine. But regularly working out of a large open-office floor plan I need help keeping focused and keeping my anxiety down, neither of which caffeine is particularly good for.
> "I’ve been able to almost double it by adding a ferrite sheet to the back side of the stator coils to contain the coils’ magnetic field lines."
I never heard of a ferrite sheet, completely awesome! I liked the article, but IMO the title is a little misleading. What I gathered is that he 3d printed the rotor only. I'm assuming the actual 4 layer pcb was etched. The rotor was still wound manually. The hall sensor still soldered by hand.
The print notion implies production automation, which is my only gripe. His hackaday has a more accurate title "PCB Motor".
doesn't PCB stand for "Printed Circuit Board"? So it's still mostly printed.. The rotor is 3d printed, and the stator is manufactured via PCB techniques. I understand what you mean regarding it not being totally printed though.
While “PCB” does mean “Printed Circuit Board”, it’s kind of a misnomer. The word “printed” doesn’t really accurately describe the process used to make PCBs.
They're standard printing techniques, just not "squirt something out of a nozzle" printing. With the exception of drilling and through-hole plating, the processes used in PCB manufacture would be entirely familiar to any experienced printer.
> “Tell me something good” isn’t meant to be a magic solution.
From a user aspect, I'd imagine the news that's curated to me would be arbitrary. A better phrase for Google to listen for is..."What a shitty day." Then Google could counter with "today may have rained shit for you without an umbrella, but these people are enjoying sunshine."
I'd laugh from the sarcasm, and who knows, it might drive up some sales for Google after I break my Google assistant and have to buy a new one.
Needless to say, I prefer laughter as my cure all over positive news that makes me look on the brighter things. On a positive note to my fellow HN readers....HAPPY FRIDAY!
"Their algorithms are designed to pick up on stock prices fluctuating before major corporate announcements, indicating that those buying or selling have insider knowledge..."
As someone who has coded high frequency algos that tracked orders and fill rate velocity, I love this little tidbit of knowledge that FINRA utilizes it's own types of analysis. It intrigues me to imagine the accuracy and dismissal of false positives. sorry nerding out on the tech
What I always thought to be interesting is by analyzing those pre-announcement movements. We all know there are always people trading on insider information so it would be possible to use those pre-announcement movements to your advantage. If you see the stock price dropping before the announcement, then best to unload your shares or vice versa.
This doesn’t work because there is no insider trading in most cases, and even if there were, you might be fooled by mass idiots trading the opposite directon of the insider.
There absolutely has to be tech analysis of a trader's entire portfolio or majority of their trades in order to really investigate before it passes off to human review.
The real beauty in this statement is the merging of fundamental analysis (news releases, ect.) with tech analysis. I don't mean tech analysis in the context of pivot points, sma's, rsi's, ect...I mean tech analysis on the evaluation of the winners of a significant price movement and their entire trades and current portfolio. THAT is the mind boggling algo.
Just b/c a trader makes x amount on a move doesn't mean they had privileged info. A tech eval has to eval their entry and exits to see if they were prime/ideal moves and most importantly their order size and order type, but it ultimately comes down to pattern evaluating their order history across multiple assets and see if their transaction history is generally successful and positions are taking prior to news release...then flag for human review and substantiate evidence.
They're probably reviewing these things ex-post, quarterly or something. It's pretty straightforward to do this analysis, i'd say. Look for people that consistently long/short shortly before a substantial favorable dislocation. People doing HF are going to be picking up small dislocation, so a move-magnitude filter weeds them out. No discretionary traders are going to be as consistently correct and consistently well-timed. IMO it'd be a pretty straightforward filter to write.
I don't think this is accurate (in the US), and very dangerous advice if you are wrong.
Not only does it contradict every post-hire training I've ever sat through, but Martha Stewart didn't go to prison for the fun of it-- she was a recipient of insider information three or four degrees removed from the source. It was very much illegal for her to use other people's insider information.
The standing definition is that if you are trading on knowledge not available to the public regardless of how it was sourced or laundered, it's insider trading. I'd genuinely like to see any references you have that can attest to this more lenient interpretation-- it seems entirely self-defeating.
> Martha Stewart didn't go to prison for the fun of it-- she was a recipient of insider information three or four degrees removed from the source. It was very much illegal for her to use other people's insider information.
Martha Stewart went to jail for lying to the Feds, not insider trading, IIRC.
> It’s legal to use other people’s insider information. It’s only when you’re the source directly or indirectly that it’s illegal.
This is dangerously incorrect in the US.
You may not use ANY material business information that is not available to other traders.
Now, you may do your own analysis of the business or the market and act on that. You can hire private investigators to dig through public trash to monitor pizza consumption and act on that. You can even use public web APIs to calculate actual customer acquisition numbers (shady, but probably just on the technically legal side of the line) and act on that.
But, if you have any information about a company not generally available to the public, you may not act on it.
The “manipulative and deceptive devices” prohibited by Section 10(b) of the Act ( 15 U.S.C. 78j) and § 240.10b-5 thereunder include, among other things, the purchase or sale of a security of any issuer, on the basis of material nonpublic information about that security or issuer, in breach of a duty of trust or confidence that is owed directly, indirectly, or derivatively, to the issuer of that security or the shareholders of that issuer, or to any other person who is the source of the material nonpublic information.
The list is long but not total. If you happen to overhear something at lunch one day that’s fair game. The chain can be long and thin but it needs to exist. Aka A lawyer who’s client is the husband of an accountant for a company trying to do a takeover and your out of luck. Now it’s safer to shorten that to non public information = off limits, but not accurate. https://www.americanbar.org/content/dam/aba/administrative/l...
‘The Court, however, determined that, for a tippee to be liable, “the insider personally [must] benefit, directly or indirectly, from his disclosure.”35 In the Dirks case, the insider who provided the confidential information did so to expose a fraud in the company, not for any personal benefit. Therefore, the Court held, the insider had not breached his duty to the company’s shareholders, so the defendant (tippee) in Dirks could not be liable for insider trading.‘
the bigger irony is that the SEC and FINRA were doing exactly what one of the hackers said they were doing, but got them - Ukranian and Russian trading firms - to settle over $10m just because they happened to know the other traders and would try to prove it in court that way if they didn't settle.
okay, knows prominent traders and hackers who trade US equities from Russian timezones, small world?
I don't see that implication in the article. I think you're referring to this part "your guys were detected. They were trading with very big money and there was a lot of fuss about them, about how it’s not the season and when it was the season they traded."
This excerpt most likely implies that the inside trades were for commodities (future contracts) and was sent to one of the relative people involved in the hack.
What would be irony (but of course is speculation) is if any of the brokerages that the hackers submitted trades thru did front-running (matching their trades at entry).
"I don't see that implication in the article." - quackerhacker
> Since 2010, the SEC’s Analysis and Detection Center has joined Wall Street’s self-regulator, the Financial Industry Regulatory Authority (FINRA), in monitoring the markets for signs of insider trading. Their algorithms are designed to pick up on stock prices fluctuating before major corporate announcements, indicating that those buying or selling have insider knowledge
> One defendant in the civil case, David Amaryan, whose company Copperstone Capital won an award for best Russian hedge fund in January 2015, claimed that one of his employees devised an algorithm to pick up early trades occurring on the market and mimic them. The logic being that the early trades were made on the basis of someone else’s insider information. ... Amaryan and his three companies agreed to pay $10 million to the SEC.
IANAL but this is an interesting legal precedent if true. Since this was an out of court settlement I assume there are no public records of the decision?
it wasn't out of court, this is the SEC's modus operandi
there's no precedent here, the government always does stuff like this
they got bullied in a civil case, the prosecutor caught them in a lie as they misjudged how the US government will nail them, and then they accepted a settlement deal
The SEC's problem is that their interpretation of laws are very nuanced and they need to avoid jury trials and appeals courts at all costs. Financial crimes are hard to prove and it is hard to determine if they are actually crimes. Yes the executive branch (SEC) says "acting like this is criminal wrongdoing so we will try you in civil court and also tell the Department of Justice", and this is reflected in the social contract that people imagine to be so, but the judicial branch and the constitution doesn't necessarily have a way to agree with the SEC. The jury in the lower trial courts are also hard to convince, because proving intent and proving which law was broken is extremely hard, all while going up against the wealthiest defendants on the planet.
The SEC does no-admit no-deny settlements because of this. The negotiation amounts are very informal between lawyers. So just kickback and relax, emphasis on kickback.
That Ukrainian voluntarily came to clear their name and got tripped up during cross examination. Stay opened up to a perjury charge or advance towards "settling" with the US just like their "perpetual settlement" with Ukranian authorities.
I haven't experience any error 53 codes on the devices I've repaired, but if this is true... Wow! That's really shady of Apple.
I'm starting to get the feeling that the moves they're making (like charging for Apple radio [not Apple music], and now disabling phones with unauthorized repairs) is their response to their recent report of declining iPhone sales. Disappointing if this is true that these changes are at the expense of their end users and fans (and I am a fan).
I think this part is the most interesting: by manipulating Xcode, the spies could compromise the devices and private data of anyone with apps made by a poisoned developer
I know iOS allows us to block an app from utilizing data over cellular, I guess the concern would then be on wifi networks.
I've been using mongo on 39M+ records (tracking financial tick data) across 73 assets (collections) and my queries take anywhere between 2-3mins depending on complexity.
You can always run db.currentOp() in the mongo shell to see what process is taking forever as well.
Let me clarify why though, there methods of optimizing a query by adding another field, but since I have to traverse my records with the sort() cursor my queries take that long.
I don't get this. If any relational database choked with that small number of rows, it would be thrown away immediately. That's a couple of orders of magnitude too slow.
>"Using the WebRTC native library allows us to use a lower level API from WebRTC (webrtc::Call) to create both send stream and receive stream."
So I'm gathering that discord's voice servers receive multiple persistent connections, then compress the audio streams for delivery to each end user. THIS part is where I can't imagine the on-the-fly cpu usage. Each client's receiving compression needs to also negate their own audio to prevent an echo effect (no point to hear your own voice), but it also means separate compression streams per user.
>" All the voice channels within a guild are assigned to the same Discord Voice server."
I imagine this helps significantly with I/O in converting live streams into 1 stream per end user. I've dealt with video compression (only in ffmpeg) and live syncing time stampings, and I can say from experience that, this is no easy feature. I understand this is audio streams (so lower overhead), but still the persistent voice server needs to handle the incoming connections, web socket heartbeats (negligible), compression (high I/O), and deliver the streams (high memory usage too).
I'm impressed, but would love to hear the specs on the media servers and their DL/UL speeds. My old setup to deliver live video (in sync and compressed) was 6 mini-itx's, 4GB of ram per board, and i3's...my bottleneck was my isp, which I solved with multiple docsis modems and an internal switch (each board had 2 ethernet ports).