Show Idle (>14 d.) Chans
← 2022-06-19 | 2022-06-21 → ↓
busybot[asciilifeform]: Current BTC price in USD: $20599.04
dulapbot: Logged on 2022-06-20 12:11:51 busybot[asciilifeform]: Current BTC price in USD: $20599.04
awt[asciilifeform]: pestbot: ping
asciilifeform: seems to have logged
asciilifeform: still seeing the [asciilifeform|asciilifeform...] lolbug
awt[asciilifeform]: yeah that's fucking annoying
asciilifeform: ( almost certainly hearsay dupes are getting relayed from asciilifeform's station to dulapbot's )
billymg[asciilifeform]: asciilifeform: regarding syncing of line indices between logotrons, what if we added a field containing the hash of speaker (minus hearsay), chan, timestamp, payload to the db?
asciilifeform: oh and the 'perpetually 1 msg behind' thing again
awt[asciilifeform]: pestbot: ping
awt[asciilifeform]: Pestbot up to date. Not sure what's going on there.
asciilifeform also up to date on both sides
billymg[asciilifeform]: backfilling that field would also fix the problem of ossasepia and lobbes logs getting out of sync with nsa logs
bitbot[asciilifeform]: (asciilifeform) 2022-04-27 billymg: i wanted to include ossasepia links too, but out of sync
awt[asciilifeform]: system times are close?
asciilifeform: on both boxes within 5sec
asciilifeform: ( the most obv. q is, wai does it getdata almost erry time ? )
awt[asciilifeform]: asciilifeform: actually looking at the pestbot logs I'm seeing the exact same thing. Dunno how it responds instantly.
awt[asciilifeform]: This is the missing message from the first GETDATA request: BROADCAST (asciilifeform) 2022-04-27 billymg: i wanted to include ossasepia links too, but out of sync 2 f6daf3650616b7a533c2c8e04fbcf926c84b6626ec3aab8585479dc7098c0ea9
awt[asciilifeform]: ok ok hmm maybe has something to do with bounces?
awt[asciilifeform]: the loggers are how many bounces apart?
awt[asciilifeform]: the loggers and bots are most likely to be farthest apart
awt[asciilifeform]: so log quotes aren't making it all the way to the other logger, and possibly poorly connected bots, such as pestbot.
asciilifeform found that max_bounces was set to 3 on asciilifeform's station; lessee if changing to 5 does anyffin
asciilifeform: ( per current spec, rec'd value is 5 )
awt[asciilifeform]: aha default is currently 3
asciilifeform: seems to have cured (or at least temporarily?) the 1-behind thing
asciilifeform: lessee if cured bot echo
awt[asciilifeform]: Will know next time bitbot quotes
dulapbot: Logged on 2022-06-20 12:51:34 asciilifeform: lessee if cured bot echo
asciilifeform: echoed on asciilifeform's station ^
awt[asciilifeform]: Yeah I see it.
asciilifeform: and no longer shits out getdata after erry msg
asciilifeform: pestbot: ping
asciilifeform: ^ also seems to work as expected
asciilifeform: still not obv to asciilifeform why a bounce cut of 3 would cause erry msg by asciilifeform himself to get 1-behind
asciilifeform: bounce dist from asciilifeform's station to dulapbot's is 1
awt[asciilifeform]: possibly stuck in buffer while waiting for getdata caused by missing log quote.
asciilifeform: the getdata goes to asciilifeform's station tho, neh (where else)
asciilifeform: which oughta answr ~immed
awt[asciilifeform]: yes - but later messages are stuck in the queue nonetheless until their timestamp passes the expiration
asciilifeform: awt: is it possible that current blatta somehow preserves bounce counts when answering a getdata ?
asciilifeform: ( rather than issuing the correct one, which is always 1 , when answering a getdata )
awt[asciilifeform]: asciilifeform: bounce count is logged so we can check
awt[asciilifeform]: it's the integer after the hash
asciilifeform: in the paste, they look to be correct ( if asciilifeform is reading'em right )
asciilifeform: hmm awt is there any mark to distinguish getdata responses in the log from other msgs ?
asciilifeform: ( currently dun seem to be? )
awt[asciilifeform]: asciilifeform: no.
asciilifeform: given what asciilifeform can see in the debug log, remains a puzzler wai a bounce cut of 3 on asciilifeform's station would cause the behaviour seen earlier in dulapbot's
asciilifeform: ( where setting to 5 -- appears to cure )
asciilifeform: esp. given that dulapbot's is still set to 3
awt[asciilifeform]: Possibly blatta only checks the bounce count before rebroadcasting and not on receiving.
asciilifeform: this is correct per current spec fwiw
asciilifeform goes to look to make sure
asciilifeform: hm nope, lol
asciilifeform: 'station must reject messages which have experienced more than a preconfigured number of bounces' 3.3.1.2
asciilifeform had fughoteen that he'd in fact remembered to properly specify this, lol
awt[asciilifeform]: Yeah looks like there's not bounce check on reception in blatta.
asciilifeform: bounce path from pestbot to dulapbot is still 3 tho, no ? (pestbot -> billymg -> asciilifeform -> dulapbot)
asciilifeform: so still can't figure out why a cut of 3 would've caused a loss
bitbot[asciilifeform]: Logged on 2022-06-20 17:10:56 asciilifeform: so still can't figure out why a cut of 3 would've caused a loss
asciilifeform: should set on asciilifeform's station to 3 again ?
asciilifeform: (atm is 5)
awt[asciilifeform]: No GETDATA from pestbot.
asciilifeform: indeed no getdata's issued on its end since set to 5
asciilifeform: (since asciilifeform's station, that is, set to bounce cut 5)
asciilifeform: i'ma set it to 3 again, lessee if same as prior
bitbot[asciilifeform]: Logged on 2022-06-20 17:10:56 asciilifeform: so still can't figure out why a cut of 3 would've caused a loss
asciilifeform: made absolutely no diff
asciilifeform: pestbot: ping
asciilifeform: still nope!
asciilifeform: ( the failure isn't reproducible by setting asciilifeform's station back to bounce cut 3 )
awt[asciilifeform]: Maybe if you can find that original log quote that started it off, it might have come via a longer route
dulapbot: Logged on 2022-06-20 12:11:51 busybot[asciilifeform]: Current BTC price in USD: $20599.04
awt[asciilifeform]: I have the bounce count logged as 2 for the first quote this morning.
asciilifeform: aa there we go
asciilifeform: 1behind again
asciilifeform: helloworld
asciilifeform: helloworld2
asciilifeform: helloworld3
awt[asciilifeform]: pestbot also sending GETDATAs
asciilifeform: nao let's back to 5...
asciilifeform: helloworld1a
asciilifeform: helloworld1b
asciilifeform: helloworld1c
awt[asciilifeform]: You'll need to wait for the buffer to dump
asciilifeform: (still 1 behind atm)
awt[asciilifeform]: order_buffer_check_seconds defaults to 180
awt[asciilifeform]: order_buffer_expiration_seconds defaults to 120
asciilifeform: hm still 1behind
awt[asciilifeform]: http://paste.deedbot.org/?id=3-d1 << there are way to many GETDATA responses here
asciilifeform: loox similar to dulapbot's, but the latter's has no 'out of order' marks
awt[asciilifeform]: might need to wait two cycles for the buffer to completely clear and write everything to the long buffer.
asciilifeform: hm seems to have worked
bitbot[asciilifeform]: Logged on 2022-06-20 17:29:41 asciilifeform: hm seems to have worked
asciilifeform: still synced
awt[asciilifeform]: pestbot had to do a GETDATA when it got 'chaser'
asciilifeform: hm interesting
awt[asciilifeform]: Which is actually really weird because I do see the log quote prior to the initial receipt of 'chaser' in the pestbot station log.
asciilifeform: awt: seems as if could be a bug triggered by reordered packet arrival
awt[asciilifeform]: Could be a netchain problem.
asciilifeform: awt: easily, but not yet obv. how, from the debug barf ( all the visible bounce paths were <= 3 long )
awt[asciilifeform]: yeah I don't think it's the bounce count
awt[asciilifeform]: Issue seems to arise for stations who speak immediately after a log quote
asciilifeform: hmm, awt , what if effect from netchain 'fork' (entirely permitted situation, but is it handled correctly in blatta?)
asciilifeform: i.e. 2 msgs with shared netchain parent
asciilifeform: seems possible: speaker 'a' speaks, and he saw msg 'm', and at ~same time 'b' speaks, but he not seen it yet. 'b' ends up issuing a getdata and embargoing m.
asciilifeform: err, embargoing a's msg
asciilifeform had a thought recently, that just about all of the gnarly embargo buffer logic in pest protocol is only req'd because irc frontend is a 'teletype', i.e. immutable
asciilifeform: if were mutable (a la heathen chats) would not need to embargo, in principle
asciilifeform: simply, we aint there just yet.
awt[asciilifeform]: what would be an example of mutation?
asciilifeform: awt: well, for starters, all replays; the receipt of any out-of-netchain-order msg; the eviction of a hearsay by an immediate
asciilifeform: ... and messages with absent chain predecessor (net or self) could, in 'mutational' pestron, be displayed immed, rather than buffered
asciilifeform: naturally this would require a custom gui thing, in place of irc teletype, tho.
awt[asciilifeform]: ah ok gotcha
asciilifeform: ( and a quite different interface for bots, somehow )
asciilifeform: ahaha lol getdataism again
asciilifeform: triggered, evidently, but asciilifeform speaking 'similt' with awt
asciilifeform: loox like we have a reasonable repro for the bug, lol
awt[asciilifeform]: this is something I never tested
asciilifeform: *simult
asciilifeform: also loox as if asciilifeform's station aint answering dulapbot's getdata's most of the time
asciilifeform: and nao 3+ msgs 'behind'
awt[asciilifeform]: yeah they're likely in the order buffer
awt[asciilifeform]: You can decrease the interval on the bot station to dump 'em out faster for a temporary fix
asciilifeform: ( high on asciilifeform's wishlist is some means for turning knobs on a bot station w/out disconnecting the bot; but 'can't have errything at 1ce' )
asciilifeform current thought : possibly when 'master' mode implemented, bot can take pest cmds from master via direct msg
awt[asciilifeform]: That would be nice. Wouldn't need another interface, like the thought I just had which is the ability to periodically reload the config from a config file that could be edited.
asciilifeform: that'd be useful, so long as config includes literally all knobbable state
asciilifeform: ( which would probably be a bitch to keep in sync with console-changed knob settings )
asciilifeform: imho 'take cmds from master' would be the Right Thing for 'headless' stations
asciilifeform: awt: theoretically could still operate a pestron via irc frontend, but perhaps the Right Thing would be for the buffer logic to live in a separate glue (given as irc offers no way to represent 'changing the past')
asciilifeform: ... whereas pestron per se could be substantially less 'stateful' than currently
asciilifeform: (conceivably, the hearsay buffer could stay, given as hearsay eviction typically takes place within ~1s, packets are ~never delayed by moar than fraction of a second)
asciilifeform: the [file:///home/stas/pest/FA/b/pest_spec/pest.html#412-order-buffer]['order buffer'] otoh would be superfluous in a 'mutable' pestron.
asciilifeform: ... the 'order buffer' otoh would be superfluous in a 'mutable' pestron.
awt[asciilifeform]: that would be really nice
awt[asciilifeform]: Could create a relatively simple curses app for display
asciilifeform: ( atm order buffer dun add to the 'l2+ spam resistance' of a station at all, cuz contents get flushed to console anyway even if no answer to getdata is received... )
asciilifeform: awt: asciilifeform in particular historically not relishes console irc clients (tho using one atm for pestnet) given as they break cut&paste horridly
asciilifeform: (inserting spurious line endings)
asciilifeform also on most machines hasn't a shell which supports utfism
signpost[asciilifeform]: oh, they probably have a page-layout: pls-no-page-numbers-plspls; and so on.
signpost[asciilifeform]: and somewhere some autist is very proud that he knows them all.
signpost[asciilifeform]: omg: srsly-no-crapping-the-url-onto-every-page;
signpost[asciilifeform] was amused to learn that JS accreted destructuring-bind recently (sorta)
signpost[asciilifeform]: would be nice if one's pest station provided a sane interface to which w/e UI can be affixed.
signpost[asciilifeform]: IRC client as UI comes with all sorts of baggage, but the client and server distinctions are still useful.
asciilifeform: signpost: indeed. but in 'mutable' scheme contemplated above, would have to be sumthing other than irc
asciilifeform: afaik there aint any off-shelf substitute
asciilifeform: ( nor do any, afaik, off-shelf chat clients , support concept of a mutable log )
signpost[asciilifeform]: nah, and this is the proper time to reevaluate, when temporary measure (IRC UI) threatens to backflow into the design.
dulapbot: Logged on 2022-06-20 14:39:49 signpost[asciilifeform]: oh, they probably have a page-layout: pls-no-page-numbers-plspls; and so on.
signpost[asciilifeform] just emphasizes that blatta growing a ncurses UI directly would be inferior to blatta providing a local API interface with which to pestulate.
signpost[asciilifeform]: allows both the ncurses UI and bots to interact with the same station.
asciilifeform: signpost: imho entirely reasonable to separate 'skin' and pestron. simply must remind that there aint atm anyfffin in the way of a suitable 'skin', nor would be particularly simple to bake outta existing chatrons afaik
asciilifeform: http://logs.nosuchlabs.com/log/pest/2022-06-20#1007899 << this is horrendous and, observe, awt , our logs are again outta sync, despite asciilifeform having given the dulapbot station ample time to sync
dulapbot: Logged on 2022-06-20 14:39:49 signpost[asciilifeform]: oh, they probably have a page-layout: pls-no-page-numbers-plspls; and so on.
signpost[asciilifeform]: nope, 100% agreed.
asciilifeform: (and by all indications this morning was 100% synced)
awt[asciilifeform]: asciilifeform: perhaps signpost's message had an old selfchain/netchain.
asciilifeform: possibly, tho doesn't explain why triggered massive cascade of getdata's from dulapbot (which supposedly 'had errything')
awt[asciilifeform]: in anycase somehow not everything is getting synced to the bot station initially.
asciilifeform: http://paste.deedbot.org/?id=YgDo << what these oddities look like on dulapbot end
signpost[asciilifeform]: dulapbot is just trying to trigger me with rubbing CSS in my face.
signpost[asciilifeform]: it wont work; I can't even feel it anymore.
awt[asciilifeform]: Same GETDATA barrage happening on the pestbot station.
asciilifeform: ^ from above, can clearly see that asciilifeform's station is relaying obvious dupes to dulapbot's
asciilifeform resigns to fact of having to zap the #p log on dulap again at some pt, after bug fixed. cuz atm it's again fulla oldrubbish
asciilifeform: this is why prod
awt[asciilifeform|asciilifeform]: Seems like netchain handling is bad, since on a new station, some or all messages from a handle don't start syncing until they speak.
asciilifeform: imho a logotron where gibblets month+ old can randomly appear in the midst of conversation aint of much use (not to mention will insta-desync from e.g. billymg's)
asciilifeform: the whole 'teletype' paradigm is, as signpost points out, leaking into pestronics to much annoyance
asciilifeform: possibly billymg's logger worx correctly because >1 peer. or because had ~100% uptime for ~whole duration of pestnet to date. nfi which. but new stations oughta work even if with 1-peer link , lol
awt[asciilifeform]: yeah I'm going to have to run some specific tests to figure out what's going on. No idea rn.
asciilifeform must bbl
asciilifeform will leave dulapbot and its station running, possibly can help in awt's debugging. but recs folx not to rely on dulapbot's #p log for any other purpose
awt[asciilifeform]: Found a potentially relevant comment in the blatta code: # TODO how to handle out of order unrequested but not stale messages subsequent to a message in the order buffer?
← 2022-06-19 | 2022-06-21 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code