Rockset Podcast Episode 2: Logistics SaaS Real-Time Analytics

About This Podcast

TruckX’s Founder Tapan Chaudhari walks through his hardware and software platform that helps trucking companies’ and fleet managers better track their assets. In this episode, we discuss the move from batch to real-time analytics and the shift from on-premise to serverless.

Gio Tropeano:

All right. Welcome to "Why Wait? The Rise of Real-Time Analytics, the Rockset podcast, where we talk with real engineering leaders about the intersection of analytics and data. I'm Gio Tropeano of Rockset, and I'm here with my co-host today, Rockset co-founder and CTO, Dhruba Borthakur. This episode, we are joined by Tapan Chaudhary of TruckX, an IOT platform for transportation, providing ELD compliance, telematics and dash cams. In addition to scheduling, dispatch and, and ELD devices for fleets. And you guys are based out of Mountain View, California, correct?

Tapan Chaudhari:

That's correct.

Gio Tropeano:

Wonderful. Tapan and Dhruba, welcome to Why Wait and Happy St. Patrick's day! We're filming and recording on St. Patrick's day. So happy St. Patrick's day. Before we kick it off for our listeners and our viewers, please share your thoughts on our community Slack channel at Rockset-community.slack.com. So Tapan, let's start off with what TruckX does and what problems you're solving for your customers.

Tapan Chaudhari:

Sure, so myself, Tapan Chaudhary I started TruckX. It's been like four and a half years. We focus on telematics compliance sites, IOT platform. We have two different IOT devices that we work with, and it goes on the trucks on the road, right from location trackers, simple trackers to advanced trackers with have temperature sensors, and other IOT devices that connect to it. We have electronic logs. These are logging devices that is used by the truck drivers to record how many hours they're driving on the road. Then we have cloud dash cam. So these cams are connected on the windshield. It looks outside, inside for the driver. It has some AI on it, on the edge it's cloud connected records live video, and we provide value to the trucking company owners.

Gio Tropeano:

That's awesome. So, so you're not just a software platform. You also have physical devices that your customers utilize in order to speak to the software, correct?

Tapan Chaudhari:

That's correct, it's a combination of hardware and software.

Gio Tropeano:

Wonderful. Do you happen to have any of those devices handy?

Tapan Chaudhari:

I have a bunch of them. Yeah.

Gio Tropeano:

Show me. Walk us through just a couple of them. This is, this is not only audio, but also visual for, so for our viewers, that would be awesome.

Tapan Chaudhari:

So I'll start with the electronic logs. These are go on by the mandate. So this is like a very small device. These are the ports, like a diagnostic port on the truck. So it goes in, it has Bluetooth that has some GPS, it talks with the mobile app or the tablet. And then I have the bigger brother of that. It's this one, it has, it comes with a rubberized fabric and a docking station and stuff so. It's it's a big one. It's tethered into the truck. So it's just wired into the computer of the truck so we can get all the readings from the truck, like the speed, the RPM, and all that. Then I have these asset trackers with me. So these trackers can, it has a huge battery that can last for almost six months. And plus it has a wired connection. So it can do live location tracking.

Tapan Chaudhari:

It can talk with other devices like these temperature sensors. These are Bluetooth temperature sensors. They work with them wirelessly. We have a bunch of these different types, like wireless release, boot sensors and stuff like that. That are like smaller brother of that. That can be hidden tracker again, talks with the different devices. And this is the new one I was talking about, was the dash cam. So this is a cloud connected camera. So, so yeah, these are like bunch of devices, which we have. And then we have our mobile apps for the driver. So these devices talk to the mobile app locally as well when there is no internet. And when there is internet, it talks directly to the cloud as well.

Gio Tropeano:

So all of these you units and tools talk to the software platform, right?

Tapan Chaudhari:

That's correct.

Gio Tropeano:

Typically your customers then are fleet management operators, is that correct?

Tapan Chaudhari:

That's correct. Yeah. So these are people who are managing their fleets. It could range from like, even like few trucks to all the way to 100 or 500 trucks, a thousand trucks.

Gio Tropeano:

So what's the size of data that like one customer, big data sets like on a daily basis, or let's say a daily basis. Like how, how what's the range there that a potential customer could be managing data-wise?

Tapan Chaudhari:

It varies a lot. Yeah, it varies a lot. Like just the location tracker itself, anything from like all the way to 10 seconds, every 10 seconds to 30 seconds we've been, right. This is coming only from one truck. And this is just the location data. It comes with other driver behavior stuff as well. Then temperature sensors that's recorded every 30 seconds as well. So we can the temperature and the load status, the dash cam that dash cam also does its own light tracking. It has its own SIM card in it. So again, that's another 30 seconds. I mean, one thing, every 30 seconds. Right?

Tapan Chaudhari:

So the data is very interesting, right? I mean, you guys know it much better. There is a size of data where in total size, but it gets very interesting when you have like small pieces and large number of small pieces of data. And that's where things are very interesting when we kind of collect all these data and then put, put it together in the cloud. So even though dash-cam might say, okay, we have huge video footage, it's okay. When it's like a small meta data and then a huge kind of a blob of data that goes as a video, but in testing, things come in when we have all these different devices and we try to produce a cohesive data to the fleet manager.

Gio Tropeano:

So then you just kind of walked right into my next question. So how are, how are the fleet management kind of decision makers or operators? Like how are they using the data or the analytics to, to solve their problems?

Tapan Chaudhari:

Yeah. So first of all right, I mean, we provide them a visibility platform. So they are able to kind of track their assets in real time where they are, what they are doing. When you talk about analytics, we provide them several options. Like they can see the utilization of their asset real time. So we kind of build up the real-time kind of content to them all the time. Seeing how many hours the asset was driving for, when it was stopped for how many hours it was stopped at a particular location, also analytics about the driver. So how many hours the driver was driving for a given day for a given week or a month or a year. So you can actually see how much kind of you ended up paying the driver. And then how much the driver was already, I mean actually driving on the road. Then interesting things more can be done, which is take this data, map it against the truck miles, how many miles the truck actually did and map it towards the drivers usage saying, okay, is the driver driving more in LA, which is a heavy traffic area.

Tapan Chaudhari:

So even though the driver is driving for two hours, the driver is only driving for 15 miles, right. Which is not so productive. Maybe find a better time for the driver to drive in LA rather than in the peak hours, to all the way to can we map fuel data? So we get the fuel consumption from the truck as well. So now how do we correlate the fuel data with the driver hours and with the truck hours? So, and this is just a beginning, right? I, when we get the DTC codes, which is the fault codes. So when we get any faults in the engine, how do we correlate with the usage of the truck and how it was consumed, maybe depending upon the speed, the RPM, right? I mean, whether the truck was just under high pressure, high RPM and the, the coolant temperature was higher due to the faults happen sooner. So there's a lot can be done. And we are just at the, at the brink of getting this all started.

Dhruba Borthakur:

Thanks for explaining that. I think you brought up a very interesting point. You talked about two types of data. It looks like there, right? One is the type of data that you're collecting, which makes your future truck routes, or timing's better. Right. But you also talked about collecting metrics or events from the truck, which is, let's say there's a fault happening in the truck or something like that. Right. So those, I'm guessing here is that some of those events might need more real time. Fix or some more real time decision-making based on when those events arise versus the other works. So could you tell a little bit about how about your real-time analytics capabilities for some of our data sets versus stale analytics that you might be doing for some of your other datasets?

Tapan Chaudhari:

So, okay. So let's talk an example of a, kind of a stale analytics, right? So there is something in our trucking industry called IFTA, IFTA there is like a calculating mileage of a truck in any given state. So given a month, I should be able to generate, our system should be able to generate a report, which tells, okay, the truck has driven 500 miles in California, 2000 in Arizona and other 2000 in Texas. Now this kind of analytics, I mean, we don't care if it's live or not. I mean, we just calculate midnight. We have a script that runs goes through the location that got collected over the day and then to expect, additional miles in that report generated for this date. And then whenever they're trying to generate a report, we just add them up and show them a quarterly report or a monthly report.

Tapan Chaudhari:

And that's kind of on demand, but this is kind of a, to Dhruba's point, like stale analytics or aggregation, so to call it. Real time analytics is something where we have these driver behaviors, right? So we have driver behavior that runs on the edge device itself. We have the utilization part, right? So we get the location from the truck all the time. Now, once we get the location, we need to determine what's the state of the truck. Like just based on the asset tracker, whether the truck is actually moving right now or does it parked. So we determined, okay. I mean, if the truck was stopped at a signal that should not be a parked situation, it's still, the truck is in transit.

Tapan Chaudhari:

So we have a live analytics, so to call it, that runs on the server, which determines the previous status of the location and kind of based on that current speed, we try to determine whether, what's the current status of this asset. So that's kind of one example, which is still not a very heavy analytics, but as in, when you have a large set of devices on the field, the problem grows.

Dhruba Borthakur:

Yeah, no, I get it. So essentially I wanted to try to figure it out the different characteristics, of stale analytics versus real time analytics. So you explained to me that there are certain things that you really want to do real time analytics on, right? So that happens on your server. Tell me a little bit about how these analytics services to your users, your users could be truck drivers or your users could be fleet operators or other people who are using our system. So how do you service this real-time analytics part to your users, not the stale park because we'll leave them behind for now. What kind of like load does it put on your system where you have to do real-time, but it's also user facing to your end users.

Tapan Chaudhari:

There are two types of analytics in this as well, right? Your time. When I, when I look at it, one is when there is some dashboard where a user goes and tries to see something on the dashboard, even though those things are kind of real time, but still there is you have, it's not, it's not a push model. It's more of a pull model, right? Because someone is going in trying to look for it. So that analytics could be kind of showing the trucks on the road. And the status is right. As we talked about right. Of a truck. Now, the other thing could be, let's say, if you want to calculate EDS or do we want to calculate the geo-fencing? So we have geo-fencing feature where it can of you put geo-fence on different areas of your map. And then we should be able to generate a notification or alerts to the user in real time, when something happens, when a vehicle enters or removes, goes out from the geo-fence.

Tapan Chaudhari:

Now this, you can say this kind of some sort of a real time analytics wherein it's more proactive. You have to constantly look for this and constantly scan all the kind of viewpoints right. For your geo-fence. So right now we do support simple. Geo-fence like a circle. We have a different ones where we can support, I think maximum eight points. I would say eight lines to create like a closed graph. And from that graph outside and inside of the way that goes, of course, it puts stress to the system because we have to make sure that we use different kinds of ways to do it. Like use some kind of in-memory database, store some data, or there, things like that. So we built like a multi-tiered storage system internally. I wish I knew Rockset before, but Habibi had a bit like this multi-storage system system where our one day data stores is getting stored in Reddis.

Tapan Chaudhari:

We have in fact built a separate radius, which only stores the latest location of any asset. So it's a very small kind of a data set, but it's like really fast. And then we second tier, which kind of stores one week of data, because still when you click on an asset that are ways where we kind of use a one week of aggregated data and whenever user goes onto the platform, so we have that second tier. And then the third, third tier is like another one, which we use different kinds of databases and systems.

Dhruba Borthakur:

I see. So you essentially kind of tier your data because it looks like your queries are kind of different types. Some queries are very point type of queries where you're looking at more like a search query, let's say like where the results sets are small and you need to look at a needle in a haystack kind of queries. Whereas you also want to do some larger aggregations on larger data sets to power analytics. Do you have these kinds of both? What kind of queries and do you actually use two different systems for this, for these types of things. You've talked about ReadySet and talked about other data systems as well.

Tapan Chaudhari:

Yeah. And that's the kind of choice, right, you have to make. Wherein, okay. Now either you reduce a dataset to include the performance or kind of reduce, I mean, don't have this kind of live, expect expected behavior, right? From, from your queries. I mean, essentially everything is equated, right? I mean, you look at it. So what we try to do, as I said, for live tracking or the latest location that's highly used, right? Every time someone goes to the system, we have to show them the last known location of that asset. So we just put like one entry, there should be only one and single entry of an asset in this database. And this is all lit up in memory and resolve it from in-memory life. So it's really fast because now you can do tons of queries on to that.

Dhruba Borthakur:

That makes sense because the data set is smaller because you have kind of aggregated it and put only the latest location of every piece. Yes.

Tapan Chaudhari:

And the other thing, which I was saying a little larger, separate where in it's like seven or eight days of data, when we need to calculate the, if the driver has any violations in the last week, now to calculate these violations, we have to actually run through eight days of records and then apply the latest records and run the hours of service algorithm. It's called. It's a thing where we have the certification for the DOD about how many hours they can drive. Right? These are rules and regulations. So we have to run those on that and then show it in the UI saying, okay, and now it's not, the problem is not for one driver, right? If you log into a system you have thousand drivers, you instantly have to show the data for all the thousand drivers. So that data goes into some kind of a time series database. I mean, it's not super fast as it is, of course, but it kind of does the job.

Dhruba Borthakur:

Yeah. I mean, that's, that's a challenge for many, many people where they have to put the data in different systems to do different types of queries. What about your data? Has things like a location maybe associated with the data you have time associated with your data. Right. So it's possible that there might be some analytics that you do, which is very much time-based like you said, like latest location of a person or a truck is time-based, but do you also do any kind of indexing on other pieces of your data where you have to do indexing on, based on your say, GPS location, or you want to do indexing based on the license plate number or some something of the truck. Do you, do you need to index, does your backend need to index different pieces of data in a molecule way rather than just one time-based yeah.

Tapan Chaudhari:

Yeah. I mean, as you rightly pointed out, time was one of the kind of ones medially used in Texas in our system. But of course, apart from that we have to index based on the truck IDs, user IDs we might have to search based on the speed of a given truck to just calculate the speed aspect of it. Yeah. So the temperature rate is another one, right? If you want to kind of put a graph of temperature, but, but yeah. So we tried to use a system which can have multi-index in it rather than a single index. So key-value pairs typically don't really work well. And these kinds of systems, you need a system that can handle multiple indexes and cache them. Right. So that you can do these queries, way faster. And then I am, and this is how I know. Right. I mean, I come from a storage background, like long time. So try to kind of build our own systems accordingly.

Dhruba Borthakur:

Yeah, no, I remember the day initial days when we were starting a TruckX, and you explained to me the vision for the company that was really illuminating at the time when I went to your first time, you talked about the size and scale of the data, and you talked about caching essentially, right. To make queries faster and make things faster. Like, do you talk about size and scale? Do you usually have to do these real time analytics on most recent pieces of the data or do you do sometimes have to look back, farther back in time, or larger data sets to be able to lose some of these analytics that you were talking about for your application?

Tapan Chaudhari:

Most of the time it's the recent data, but for a longer-term data, which is the kind of violations of a driver right, let's say you want to calculate the violation of a driver for the entire year, how many violations the driver had. So what we do essentially is we actually take a snapshot of that information every day and we store it in that database. So rather than recalculating the whole stuff, you just get one entry per day, which is like 365. Interns is a piece of cake. We'll take them in like aggregate and show it to them. So it's basically, I mean, there are ways we used to do, right. I mean, either you do a dynamic rate and you don't have this information, but then when you have this information, you can roll up from any time, any point in time. So it's kind of a differential kind of incremental storage system in backup terms.

Tapan Chaudhari:

Yeah. Makes sense. So that kind of helps us to kind of build up the analytics for lab testing. But then again, the problem is if we have to, if, if, if you have to come up with some different information that you have not prepared for, then, then you're in trouble because now you cannot build the whole system again.

Gio Tropeano:

So, so Tapan, we're starting to see a general shift from building with cloud to more serverless architectures. Right. Do you currently adopt or use any serverless components in your stack? And if, if so, what insights into like value out of those components? Like what value did they provide.

Tapan Chaudhari:

As of now we don't use a serverless model. I am strong believer in microservices and entire stack is on Kubernetes. It's very easy to spin up a pod in a Kubernetes service. It's literally, it's a fork, right. A PS fork. So it's as good as serverless kind of a macro function. So, so yeah, that gives us the leverage of kind of having our own cluster and then spin up the services as in when needed and scale up and down. And of course there are a few things which we can use serverless, like that you can send alarms that are generated for that maybe to use these spare and just give it to them. And then there's a quick calculation and generate an alert, but we haven't dipped our toes over there in kind of serverless. But to me it's essentially the same thing. I mean, it's like if you have a process which you can spin up and spin down easily, you don't, it's essentially a serverless, as long as the developer doesn't need to know what's happening.

Dhruba Borthakur:

It's so funny.

Tapan Chaudhari:

Go ahead. Sorry.

Dhruba Borthakur:

I want to expand on Gio's question. So you talk about serverless and you also talked about kind of a service our software as a service that you can use, which I think you kind of said, as long as you don't have to hire too many people to manage your data, so tell me a little bit about said operational complexity of handling some of these real time analytics data platforms that you have, whether it's strategies or whether there's something else. How do you think about how many people are, how many engineers you have to have to be able to just manage and massage and keep the data happy before you can, before your application developers actually get their hands on it and try to add value to your system.

Tapan Chaudhari:

You'd be surprised. We literally didn't have any single person designated for our entire infrastructure. And the reason for that was we went with Heroku. I love Heroku. I meant if someone wants to really build a new next generation kind of infrastructure company, it's just a reincarnation of Heroku. But I mean, I've been saying for a long time, but I guess so Heroku allows you to kind of just run an application, not worry about the infrastructure at all. We now have migrated to Kubernetes. So now we have like one person dedicated for this whole Kubernetes architecture. But the ideas with Kubernetes is now that we are getting more skilled Heroku was getting more expensive because the way they bill and kind of stuff like that, it's, I don't know. They, they, they have this weird structure where in, in microservices, you don't want a very heavy process, right?

Tapan Chaudhari:

You want a lightweight process, but then you can, you should be able to scale into hundreds of instances. But it also does that if you assign a small CPU or Ram, it's more of a virtual and it's on demand. So it's not like dedicated to you. And that costs a lot and reduces the latency, increases the latency significantly. So, and if you're a dedicated CPU, then the CPU side, it's certainly huge. It is like for code and stuff. I was like, okay, I just want to run one thread, I don't want a whole machine for this. And that's the primary reason to kind of, kind of move to Kubernetes so that we can efficiently use the system where then you can either do a CPU affinity as well. If you really care about not losing, losing you in the CPU versus actually over provisioning, the sum parts of the cluster wherein using some services can handle ups and downs and latency is not a big issue.

Tapan Chaudhari:

Well, so now we have like one person who is managing and building the old CIC for the Kubernetes and managing the database. We did deploy databases internally. I strongly believe of not using kind of external services to have less dependency on the cloud services. So even the database that we have deployed is deployed internally inside Kubernetes. So yeah, I'm very happy.

Dhruba Borthakur:

Yeah, it's interesting. Yeah. At rockset also, we use Kubernetes quite a lot to deploy our own internal services. We find it worked really well when most of the time we are scaling CPU and compute our memory. But then when you scale the storage, then there are some other challenges that we find at least when are using Kubernetes, are, are things like that, those.

Tapan Chaudhari:

Balance of this, all the CPU, memory and storage from your service level, I think it's, it's easier control the cluster.

Dhruba Borthakur:

Yeah, no, absolutely. What about things like in your real-time analytics platform, do you, other things that you need to react very suddenly to, to events that are happening in your platform? You explained to me something about faults in your truck, for example, right? I don't know how quickly you need to react to them, but are, are, or do you need to build a new requests from your users where there is a need to build some of these reactive systems quickly and fast and deliver it to your applicant, to your, to your users?

Dhruba Borthakur:

What is your demand like? Is it more about offline analytics and let us know when things happen after a few hours or days, or is there, do you see more demand for the ability to have quick decision-making on some of these new datasets that you are getting?

Tapan Chaudhari:

Well, most of our data set is actually real time because it's a fleet manager that really wants to know if something is going on, like any driver behavior alerts and stuff. It's mainly around like an alerting system though. Like if you talk about real analytics, I mean, having our codes and kind of surfacing that information is, I don't know if I'll consider that as analytics per se, but the way I think of analytics is mainly something. If we have, as I said, incremental buildup of an analytics data, I mean, it's always, you can apply that increment on the previous data set you've calculated and reduce it fantastically. And you really don't have to do the whole batch processing from ground up. I mean, I'm, I'm never been a fan of a loop and stuff. I mean, so it's just interesting to me how people take these huge data sets divide by plan and have some output wherein you can actually generate those output really quickly by having an incremental data set.

Tapan Chaudhari:

But so we haven't seen a large number of those, but yeah, getting all the information real-time to the customer is of course the utmost priority for us. And as in when we scale right. Systems like Rockset, I mean, I know we have spoken before, so is, is very interesting and appealing for us to kind of just dump the old data onto rockset and kind of, it can handle all the indexes on different kinds of data we have. And these indexes are powerful then, because now I don't have to rethink of how I want to present this accomplishment. I can change it on the fly. Absolutely.

Gio Tropeano:

Well, with that in mind, what advice, Tapan would you give to other heads of engineering that are utilizing real time analytics for fleet management?

Tapan Chaudhari:

I've given up this hat of head of engineering now to someone else in our team. But what I can say is, I mean, it's kind of a for, so there are two sets of things, right? One is, let's say, if you already have an established company, if you already have an established data set with some legacy system, so that's kind of one kind of, kind of a position you're in. And second is if you're building something ground up when you don't have any customers and stuff, right. Both are drastically different. Of course my advice will be whatever is based on my first phase of the company, right? Wherein we build the system. And I said, we took some shortcuts in terms of using Heroku and others to kind of quickly build the system, not worry about it at all. And because the data set is pretty small right when you start.

Tapan Chaudhari:

So you don't really have to worry much, but kind of trying to really dig deep into what value you're building and building those incremental data sets over time will really help, even if you're stuck with your legacy systems. But if you really want to kind of swap and replace your legacy system, which kind of we're trying to do in some sense, like moving from RDS right now to different kinds of time series databases.

Tapan Chaudhari:

So this is where now the hard part comes in of how do you move the live data set, which is going from ideas to what time series database, even just for purely like location or location tracking. So we had built a system which now parallel the rights to both sides. And then slowly we cut it off, like cut off RBS on one side and then run another job, create a clone from the RDS and another job that can copy all the data, all data from our dataset, dump it to timescale because we don't want two systems to be running all the time and put some if conditions in our code saying, Oh, if data is greater than this, go here and data smaller than this go here and I mean, we don't want that to just want everything in timescale.

Tapan Chaudhari:

So running those jobs, of course they, they take time, but I think it's good to bite the bullet early on, rather than waiting for your sequel queries to time out. So we were starting to observe our queries getting slower and slower. So we just decided to kind of pull the trigger, just find some database that can horizontally scale. And yeah, so that's what I would suggest based on my limited knowledge and experience.

Gio Tropeano:

Absolutely. So, then with the next evolution then of TruckX and where you see TruckX going? What current challenges are you foreseeing your engineering team facing in that next phase?

Tapan Chaudhari:

So the next phase for us is kind of going from these smaller midsize accounts wherein the largest account Maybe we have as like a hundred trucks to going after the accounts with a thousand plus trucks. Now, even though in our system, we have tens of thousands of trucks. The information you're gonna surface for a 50 truck company is still a small data set from the small subset, from the big 30,000 or 40,000 drivers that we have. So now suddenly if you get a company which has thousand trucks in it, thousand drivers, now it's one company and all the calculations, whatever we do to produce any information on the dashboard, now your data set has increased.

Tapan Chaudhari:

So that's the challenge which we are facing right now and which we are actively solving, which does involve analytics, which does involve just a regular fetch of information, right. Which it's slower. And you have to think differently now, how do you fetch this information? Because now suddenly kind of two or three years ago, the entire user said whatever it was, right, like a thousand kind of drivers like three years ago now suddenly it's that in one company, so how do you, in your system, you cannot work that way, so you have to rethink about your system and scale it. Well, obviously the things that we are working on actively

Gio Tropeano:

That's great. And I wish you luck in tackling those challenges. A great discussion today with Tapan Chaudhari of of TruckX. Thank you so much for your time and sharing your experience about, your company and real-time analytics, all your challenges and wonderful things that you bring to the market. I think it's an awesome company. If you're looking to learn more about TruckX, visit truckx.com. You have a great website. Congratulations on that. And obviously continued success for our listeners, Here at Rockset, we're building a real-time analytics cloud-based platform that can add value to use cases similar to those that Tapan described us today. Thanks once again for joining us and stay tuned for our next episode. Thank you everyone for joining.

Tapan Chaudhari:

I think so too. I mean, this looks like a great setting to me. I mean, like having a more technical conversation, I really miss it. I mean, coming from an enterprise and storage background, doing a company in trucking is totally different, but, but yeah, it's good to kind of be nerdy and kind of have these talks. We love that. Yeah, really appreciate you guys inviting me here.

Gio Tropeano:

Absolutely. The pleasure was ours. Thanks for, thanks for your time.

Tapan Chaudhari:

Thanks Dhruba for your time.

Dhruba Borthakur:

Thanks for being here, Tapan. All right. Have a good one. Bye