>>23685645I'll kindly assume newfag, and not falseflag. Plus, I'm really bored tonight, so here goes.
The main reason people discredit fixed interval sawtoothing as as a sign of botting is because it's also represented in a Dec 2020 YouTube change that cratered CCV across the board on the platform, but also seemed to affect HoloEN users more heavily than HoloJP (users, not streamers - this also tracks with CCVID testing appearing to be user-based flagging). I'll just track it with 4 of Ina's drawstreams (to roughly compare similar audiences), but it's present in damn near everything in HoloEN during the interval of late Dec 2020 to mid Aug 2021. What's really interesting is that you can actually see the same "natural" CCV curve in the sawtoothed graphs, just with random teeth sticking out of it. It's also worth noting that the Jul 2021 and Aug 2021 basically have the same CCV, only one has teeth and the other doesn't - which shows that fixed interval sawtoothing is something that likely occurs on YouTube's side.
https://holo.poi.cat/stream/g96MFx8X800 (Dec 13, 2020)
https://holo.poi.cat/stream/uTR35XKAKIU (Dec 20, 2020)
https://holo.poi.cat/stream/JpjETRZnGd8 (Jul 18, 2021)
https://holo.poi.cat/stream/nqa9EqZR3XY (Aug 14, 2021)
Another example of the userbase getting flagged is to dig through Coco's archive and realize that most of her content (ends before Aug 2021) has curves as smooth as a baby's ass, but content with near-zero appeal to the Japanese audience gives you this:
https://holo.poi.cat/stream/NCq9K4ql47YYou can also see traces of fixed interval sawtoothing in Shitpost Reviews in 2021 (mixed EOP audience):
https://holo.poi.cat/stream/Fyd6quCBX34 (pretty clear after ~15 minutes)
https://holo.poi.cat/stream/OWvEG82V7UM (noticeable after ~35 minutes)
But funnily enough some of her best-performing Shitpost Reviews in 2021 don't have noticeable teeth, when they would theoretically be the botted examples:
https://holo.poi.cat/stream/1Mm2VgxI-nAhttps://holo.poi.cat/stream/YTTnA4MQkg0It's also worth considering that your argument is backwards - why would bots and viewfarms be reflected in fixed interval spikes? The braindead way to deploy bots is to turn them all on and leave them there (ie: hard spikes with smooth aftermath, as demonstrated by known botting from /here/). A more sophisticated bot farm might instead deploy individual bots one after the other at short fixed intervals to have them replaced at a faster rate than they get culled - which if done correctly should theoretically give a smooth graph (ie: constant repeated short spikes). Given those assumptions, fixed interval sawtoothing would mean someone's spiking bot purchases in fixed, suspiciously well-spaced intervals that are minutes apart (not seconds), in batches of a few hundred each time, to not actually drive up the CCV at all but instead just troll /#/ into writing blogposts about sawteeth on CCV graphs.
What I deduce is the yt live ccv loop:
All front-end video server reports their active session to a global mq. Each stream spawns at least 3 tally process in 3 different regions for redundancy. Each tally process instance then send their results to the global live ccv mq. The api call for live ccv takes whatever is the latest number in the live ccv mq. You can see this when one of those tally process instance crash/stuck returning the same total to the live ccv mq and create the barcode ccv graph.
Let's throw a wrench into this loop. Make the tally service "verify" every account for "bot behaviour." YT coder in their infinite wisdom decided that this task must be performed in realtime for every account in every stream. I don't see what data they have but it might be the right solution to the xrp botting/viewfarm who knows. My best guest is that their recommendation algo relies on the live ccv number.
Now we have different instances running on hardware with different performance doing this task. Naturally not all of them will finish "verifying" the same number of accounts at the same time. They return slightly different total into the live ccv mq. Mix in the smoothing effect of having the api servers caching their result, it creates that beautiful sawtooth. With more flagged viewers the bigger the sawtooth because it will exaggerate the difference in performance between the different instances of the tally process.