Kalshifair
fair
kylegendy参与话题 1消息总数 57
该用户的聊天记录定位。
聊天记录
共 57 条，显示第 1-50 条no i haven't tried that yet, but that's my next step along with switching to non-blocking and tracking loop speed
no i haven't tried that yet, but that's my next step along with switching to non-blocking and tracking loop speed
partly for fun, partly to beat the crowd
partly for fun, partly to beat the crowd
i have one thread for reading messages, one thread for the control server that prometheus polls, other threads for other things. eventually i'll pin them to separate cores to run in parallel but as of right now i assume they're all running on the same one.
i have one thread for reading messages, one thread for the control server that prometheus polls, other threads for other things. eventually i'll pin them to separate cores to run in parallel but as of right now i assume they're all running on the same one.
HA definitely multi-threaded
HA definitely multi-threaded
but if it's blocking, and i wanted to see how long a single loop iteration was, i wouldn't be able to tell if it's just because it was waiting for a message, or if it was a scheduling issue. if it's non-blocking then i can DEFINITELY know if its a scheduling issue
but if it's blocking, and i wanted to see how long a single loop iteration was, i wouldn't be able to tell if it's just because it was waiting for a message, or if it was a scheduling issue. if it's non-blocking then i can DEFINITELY know if its a scheduling issue
yes, you are right, if i make it non-blocking i would need to poll it. right now i have it set up as blocking, so theoretically it wakes up as soon as a new message comes in.
yes, you are right, if i make it non-blocking i would need to poll it. right now i have it set up as blocking, so theoretically it wakes up as soon as a new message comes in.
so for both of those reasons, i don't think that's it
so for both of those reasons, i don't think that's it
but lets say i wasn't and i wasn't responding to them, would they really wait 2-3 hours before kicking me off?
but lets say i wasn't and i wasn't responding to them, would they really wait 2-3 hours before kicking me off?
C++, i wrote the websocket client functionality myself and tested it against a small python server that would send ping frames every now and again. it definitely gets them.
C++, i wrote the websocket client functionality myself and tested it against a small python server that would send ping frames every now and again. it definitely gets them.
woof
woof
yes, my websocket class auto responds to pings with pong frames, but like i said, i have never received a ping from kalshi
yes, my websocket class auto responds to pings with pong frames, but like i said, i have never received a ping from kalshi
otherwise i guess i'll have to set my socket connections to non-blocking and measure it the way you're suggesting to know for sure if its an OS scheduling issue
otherwise i guess i'll have to set my socket connections to non-blocking and measure it the way you're suggesting to know for sure if its an OS scheduling issue
i'm otherwise not interacting with kalshi, like literally all i'm doing is connecting and subscribing to lifecycle, with no pinging or anything after that. i don't send any other REST http requests either. do you think if i don't interact for a few hours they'd kick me off?
i'm otherwise not interacting with kalshi, like literally all i'm doing is connecting and subscribing to lifecycle, with no pinging or anything after that. i don't send any other REST http requests either. do you think if i don't interact for a few hours they'd kick me off?
so you've never just stopped receiving messages and get closed out?
so you've never just stopped receiving messages and get closed out?
when you get "unsubscribed" from a channel, does it notify you? do you always get a close control frame or do you just get an EOF?
when you get "unsubscribed" from a channel, does it notify you? do you always get a close control frame or do you just get an EOF?
that's fair, and to be clear i'm not saying that kalshi is doing something wrong, my assumption has always been that it's me, i'm just not sure what it is. that said, the server returned header_timestamp_expired with a clock 16 minutes ahead still points more toward a server-side clock/auth issue for that specific event.
that's fair, and to be clear i'm not saying that kalshi is doing something wrong, my assumption has always been that it's me, i'm just not sure what it is. that said, the server returned header_timestamp_expired with a clock 16 minutes ahead still points more toward a server-side clock/auth issue for that specific event.
let me ask it differently, what should i be tracking to figure this out?
let me ask it differently, what should i be tracking to figure this out?
if i don't get that error type message, does that not imply i'm taking from the buffer fast enough?
if i don't get that error type message, does that not imply i'm taking from the buffer fast enough?
i guess i don't really know how else to prove it. i'm not gonna log when i enter a recv call and when it exits. or for my non-blocking connections how many times i call recv with nothing coming out of it.
i guess i don't really know how else to prove it. i'm not gonna log when i enter a recv call and when it exits. or for my non-blocking connections how many times i call recv with nothing coming out of it.
comparing the time i logged the raw messages coming in, to after i've parsed the messages and logged them in my tsv files, for my small sample, it's about 40 mics. the parsing speed doesn't necessarily prove that i'm taking it from the OS socket buffer fast enough though, it only implies that i get through each message quckly enough to get back to calling recv.
comparing the time i logged the raw messages coming in, to after i've parsed the messages and logged them in my tsv files, for my small sample, it's about 40 mics. the parsing speed doesn't necessarily prove that i'm taking it from the OS socket buffer fast enough though, it only implies that i get through each message quckly enough to get back to calling recv.
looks like there was a spike of messages at around 2am, i'll check that time
looks like there was a spike of messages at around 2am, i'll check that time
i'll check for timestamps
i'll check for timestamps
that's fair
that's fair
when i run it on the unfiltered ticker subscription i avg 550 messages a second, and i'm running that for the same amount of time i'm running lifecycle subscriptions. like i said before, lifecycle is only running 15 messages a second. there's just no way its because i'm not consuming fast enough
when i run it on the unfiltered ticker subscription i avg 550 messages a second, and i'm running that for the same amount of time i'm running lifecycle subscriptions. like i said before, lifecycle is only running 15 messages a second. there's just no way its because i'm not consuming fast enough
i REALLY don't think it's because i'm not consuming fast enough
i REALLY don't think it's because i'm not consuming fast enough
i log all raw TCP communication, and i didn't ever receive any "error" type message
i log all raw TCP communication, and i didn't ever receive any "error" type message
except for the final 401 i guess, that one only stops sending messages for the last 20 ish seconds
except for the final 401 i guess, that one only stops sending messages for the last 20 ish seconds
something else to note, before every EOF message i stop receiving messages for about 1-4 minutes, when the general rate of messages is about 15 per second for market lifecycle
something else to note, before every EOF message i stop receiving messages for about 1-4 minutes, when the general rate of messages is about 15 per second for market lifecycle
ohp excuse me, i meant EDT
ohp excuse me, i meant EDT
I KNOW!! i thought it was crazy too. i'm in EST, so that's what it's logging. and it doesn't match up with the reported response GMT time
I KNOW!! i thought it was crazy too. i'm in EST, so that's what it's logging. and it doesn't match up with the reported response GMT time
the "SENT" and "RECV" are my internal log times
the "SENT" and "RECV" are my internal log times
an interesting detail with the second problem, check out these timestamps: SENT 2026-07-17 03:44:12.861175512 GET /trade-api/ws/v2 HTTP/1.1 ... KALSHI-ACCESS-TIMESTAMP: 1784274252860 RECV 2026-07-17 03:44:12.937047554 HTTP/1.1 401 Unauthorized Date: Fri, 17 Jul 2026 08:00:28 GMT
an interesting detail with the second problem, check out these timestamps: SENT 2026-07-17 03:44:12.861175512 GET /trade-api/ws/v2 HTTP/1.1 ... KALSHI-ACCESS-TIMESTAMP: 1784274252860 RECV 2026-07-17 03:44:12.937047554 HTTP/1.1 401 Unauthorized Date: Fri, 17 Jul 2026 08:00:28 GMT
the second is the 401 {"code":"header_timestamp_expired","message":"header timestamp expired"}
the second is the 401 {"code":"header_timestamp_expired","message":"header timestamp expired"}
the first is that the time for connections progressively gets smaller between EOFs. 2 hours, 5 minutes, 1 minute
the first is that the time for connections progressively gets smaller between EOFs. 2 hours, 5 minutes, 1 minute
it feels like there's two problems here, but maybe they're jsut symptoms of the same issue
it feels like there's two problems here, but maybe they're jsut symptoms of the same issue
got EOF at 03:44:12.860144596, sent out my new connect request at 03:44:12.861175512
got EOF at 03:44:12.860144596, sent out my new connect request at 03:44:12.861175512
it doesn't ever appear to be reused
it doesn't ever appear to be reused
do you mean the KALSHI-ACCESS-SIGNATURE?
do you mean the KALSHI-ACCESS-SIGNATURE?
which surprised me
which surprised me
i've never received ANY ping frames from kalshi
i've never received ANY ping frames from kalshi
i'm subscribing to market lifecycle, and once its set up i just listen for the messages. could it be because i'm not pinging? i'd be surprised if that's the case since i'm reconnecting.
i'm subscribing to market lifecycle, and once its set up i just listen for the messages. could it be because i'm not pinging? i'd be surprised if that's the case since i'm reconnecting.
Checked my machine clock. Network Time is enabled, and sntp reports only +0.003867s offset from time.apple.com (~4ms). The KALSHI-ACCESS-TIMESTAMP in my logs also matches my local send timestamp within milliseconds, so local clock drift doesn't appear to be the issue.
Checked my machine clock. Network Time is enabled, and sntp reports only +0.003867s offset from time.apple.com (~4ms). The KALSHI-ACCESS-TIMESTAMP in my logs also matches my local send timestamp within milliseconds, so local clock drift doesn't appear to be the issue.
is there an easy way to check if it's properly set up on unix systems?
is there an easy way to check if it's properly set up on unix systems?
thanks i'll check it out, i've never heard of NTP before
thanks i'll check it out, i've never heard of NTP before
no i'm not using NTP
no i'm not using NTP
with ticker messages the time difference between the ts_ms and my own local time is consistently 500 ms, i assumed it was a batching thing kalshi is doing
with ticker messages the time difference between the ts_ms and my own local time is consistently 500 ms, i assumed it was a batching thing kalshi is doing
this happens every time i run, after a few hours. its nuts.
this happens every time i run, after a few hours. its nuts.
if it were a timing synchronization issue you would think none of the connects would work, right?
if it were a timing synchronization issue you would think none of the connects would work, right?
i'm definitely consuming messages fast enough lol. tell me more about this second one, "local clock is synchronized with NTP"
i'm definitely consuming messages fast enough lol. tell me more about this second one, "local clock is synchronized with NTP"
第 1 / 2 页
下一页 →