Closed t2o2 closed 2 years ago
https://bybit-exchange.github.io/docs/linear/#t-websocketorderbook25
L2 feed 20ms
2022-04-09 18:23:26.067 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.154 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.180 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.279 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.303 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.355 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:23:26.459 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
https://bybit-exchange.github.io/docs/linear/#t-websocketorderbook200
L3 feed 100ms
2022-04-09 18:15:07.360 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:15:07.506 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:15:07.705 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:15:07.864 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
2022-04-09 18:15:08.206 | INFO | __main__:sub_cb:36 - {'exchange': 'bybit', 'symbol': 'KSM-USDT-PERP', ...
Does this work as-is? I dont see anything that would trigger the L3 book callback, is this still triggering off the L2 book callback? Also, an L3 book will have more information and that would need to be parsed separately/differently. I'm not seeing any change for that either
You are right, L2 will work fine, but not L3. Will implement it and test it with L3. Thanks.
L3 orderbook feed fixed
2022-04-09 20:13:16.260 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:17.081 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.107 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.122 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.140 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.168 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:17.200 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.269 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:17.721 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:17.764 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:18.720 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:18.741 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:18.760 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:18.762 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:19.107 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:19.163 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
2022-04-09 20:13:19.180 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:19.202 | DEBUG | __main__:book2:39 - L2 BYBIT KSMUSDT
2022-04-09 20:13:19.261 | DEBUG | __main__:book3:42 - L3 BYBIT KSMUSDT
L3 books are not price aggregated, so this is not an L3 book. if you want to add some toggle between the slow orderbook (with more levels) vs the real time thats fine, but this is not an L3 book
I thought L3 is just a deeper L2, not quite sure what it means by "not price aggregated". Anyway, I will refactor it to become an option on setup instead of L3.
@t2o2 price aggregation means that for a given price you see the total size of all orders at that level. This aggregation in not present in L3 books, at a price level you will see individual order ids and their respective sizes
Added extra option for bybit feed, tested as below.
Demo code updated to reflect this.
2022-04-19 22:24:00.830 | INFO | __main__:book_slow:19 - Book slow received at 1650403440.830726 for BYBIT - BTC-USDT-PERP, with 400 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:00.849 | INFO | __main__:book:15 - Book fast received at 1650403440.849024 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:00.867 | INFO | __main__:book:15 - Book fast received at 1650403440.867789 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:00.907 | INFO | __main__:book:15 - Book fast received at 1650403440.907719 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:00.928 | INFO | __main__:book:15 - Book fast received at 1650403440.9285362 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:00.929 | INFO | __main__:book_slow:19 - Book slow received at 1650403440.929176 for BYBIT - BTC-USDT-PERP, with 400 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:01.030 | INFO | __main__:book_slow:19 - Book slow received at 1650403441.0300748 for BYBIT - BTC-USDT-PERP, with 400 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:01.030 | INFO | __main__:book:15 - Book fast received at 1650403441.030703 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:01.051 | INFO | __main__:book:15 - Book fast received at 1650403441.051583 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:01.128 | INFO | __main__:book:15 - Book fast received at 1650403441.127958 for BYBIT - BTC-USDT-PERP, with 50 entries. Top of book prices: 41277.50 - 41277.00
2022-04-19 22:24:01.128 | INFO | __main__:book_slow:19 - Book slow received at 1650403441.128887 for BYBIT - BTC-USDT-PERP, with 400 entries. Top of book prices: 41277.50 - 41277.00
I haven't introduced a new channel type at the user level. As shown in the demo code, the user still use L2_BOOK to perform the subscription.
The only reason that I expose the new channel in the websocket channels dictionary is to be clear to any future contributor that both L2 channels are available in the feed.
@t2o2 I'm flexible on the implementation but I can't think of a reason to add another channel define, even if its only for a single exchange. Thats the main argument to not add it - it would only be for a single exchange.
Description of code - what bug does this fix / what feature does this add?