XChange icon indicating copy to clipboard operation
XChange copied to clipboard

FTX Orderbooks heavly lagged in info.bitrich.xchangestream.ftx.FtxStreamingExchange

Open m1dnightc0der opened this issue 2 years ago • 1 comments

When subscribing to FTX orders books via info.bitrich.xchangestream.ftx.FtxStreamingExchange they lag up to 30 to 40 secs vs connecting and streaming say in python, so this is not a local machine issue or a ftx to local machine lag issue.

Example connection

XchangeUtil.getStreamingExchangeForMarket(market).getStreamingMarketDataService().getOrderBook(pair, params) .subscribe(orderBook -> handleOrderBook(orderBook)`

Now I thought maybe, my client was too slow consuming, so backed off but this did not make any difference

XchangeUtil.getStreamingExchangeForMarket(market).getStreamingMarketDataService().getOrderBook(pair, params).throttleLatest(500, TimeUnit.MILLISECONDS).subscribeOn( Schedulers.newThread()) .subscribe(orderBook -> handleOrderBook(orderBook)

Looking at other implementations is seems they used the grouped orderbooks endpoints (https://docs.ftx.com/#grouped-orderbooks) rather than the orderbooks endpoint (https://docs.ftx.com/#orderbooks)

I don't know reactiveX that well, but very keen to resolve this issue, so any pointers on investigation would be greatly appreciated. Will start writing some local tests to try and figure out what is up, but I am thinking it is something within the FTX API.

m1dnightc0der avatar May 21 '22 08:05 m1dnightc0der

Hello, you mean 30-40 milliseconds I guess because there is not a lag of 30-40 sec on ftx streaming orderbook

On Sat, May 21, 2022, 11:38 AM m1dnightc0der @.***> wrote:

When subscribing to FTX orders books via info.bitrich.xchangestream.ftx.FtxStreamingExchange they lag up to 30 to 40 secs vs connecting and streaming say in python, so this is not a local machine issue or a ftx to local machine lag issue.

Example connection

XchangeUtil.getStreamingExchangeForMarket(market).getStreamingMarketDataService().getOrderBook(pair, params) .subscribe(orderBook -> handleOrderBook(orderBo`ok)

Now I thought maybe, my client was too slow consuming, so backed off but this did not make any difference

                Schedulers.newThread())
            .subscribe(orderBook -> handleOrderBook(orderBook)````

Looking at other implementations is seems they used the grouped orderbooks endpoints (https://docs.ftx.com/#grouped-orderbooks) rather than the orderbooks endpoint (https://docs.ftx.com/#orderbooks)

I don't know reactiveX that well, but very keen to resolve this issue, so any pointers on investigation would be greatly appreciated. Will start writing some local tests to try and figure out what is up, but I am thinking it is something within the FTX API.

— Reply to this email directly, view it on GitHub https://github.com/knowm/XChange/issues/4489, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIWQ72YDHVLAIJP235F2QLVLCOH7ANCNFSM5WRQMMYQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

makarid avatar May 23 '22 05:05 makarid