Great. Thank you, Christine. Before I get rolling, I would like to say thank you to the Linux Foundation for organizing this webinar. We worked with some really great people and they pulled together a really great show. So, Christine, thank you very much for your help in pulling this together. So, I am Scott Stetzer. I work for Kyokusei America in the Memory and Storage Strategy Division. Kyokusei, of course, is one of the largest manufacturers of flash memory for the industry today. Back when we were known as Toshiba memory, we invented flash memory. So we know quite a bit about it. We also deliver quite a broad range of SSDs to the industry, and my particular group, the Memory and Storage Strategy Division is focused on bringing that flash storage and software expertise forward for you, the customers. So data storage is a pretty interesting topic. At least for me, it's a fairly interesting topic. Ever since the very early phases of we human beings, storing information about ourselves has been a thing. But as far back as actually putting paintings on cave walls. Of course that has progressed over time through things like hieroglyphs and stone tablets. And when they invented ink, we were putting ink on papyrus. And then we, we get to the industrial age and a very interesting change happened and we were able to put print on paper to such a degree that our data storage mechanism became books. A very useful approach to storing retrieving data. A little more appropriate to us as we move into the computer age within this last 50 to 100 years. The first method of storing data in the computer age was of course punch cards. A very mechanical process. Then we changed to linear magnetic storage, which of course is tape and tape was a very sequential access methodology using magnetics. The next big innovation was to change that magnetic approach from linear to rotating. So rotating magnetic storage. What we know today as hard disk drives and used to be floppy drives. And again a very mechanical approach to storing data. What we did for us that HDD paradigm, and that HDD paradigm has evolved over the last 35 to 40 years. When we started out that hard drive was probably about the size of the average washing machine. And over these 35 to 40 years we were shrinking the footprint of that storage mechanism. We went from washing machine size to 16 inch to eight inch to five and a quarter inch platters of magnetics, and we settled in the three and a half inch to two and a half inch range today. And while we were doing that shrinks we were also increasing the amount of data that can be stored in that ever shrinking space. Now the consistent bit about this is all of this was designed quite a while ago, all before flash was invented as a storage media. And again it's a very mechanical approach to data storage. And that mechanical approach means it's pretty much a black box. It's not terribly flexible you can read to it or you can read from it or write to it, but the ability to adjust how that device works is very limited. There's no control over latency in that mechanical spinning disk. Now over the last 10 to 15 years solid state storage in the form of flashes come into play and SSDs were quite a game changer for us in the industry. Now, initially, SSDs, they started out simply as a faster form of HDD. And this was pretty important because in order for those SSDs to become adopted, they had to plug right into the existing storage paradigm, which was the high drive SSDs today continue to be extremely important for all sorts of applications, especially consumer applications and enterprise server ecosystem applications. I can't imagine running my laptop today without an SSD in it used to have hard drives, but now I can't imagine running without an SSD. The challenge though is even up to today while all of this backwards compatibility is phenomenal and important in order to keep compatibility up. We're still limited. We're still limited by that mechanical HDD paradigm. And there's a range of storage innovators out there that are looking at new ways to bring all of this capability that flash can actually bring to the equation on beyond that HDD paradigm. One of the key innovators, of course, is the cloud or hyperscale data center. They're looking for ways that they might be able to bring that full capability of the digital storage media flash storage to their application development. So why is it that the HDD or cloud data center is a center of innovation. Well, one of the key aspects of this is they're vertically integrated, they own the entire stack in the data center. They can work to the server, to the storage to the applications, they control every aspect of it. And they're creating all of those new and wonderful applications that we use every day and expect to work seamlessly and fast. So while they're doing all of this work they're redefining and looking for how can they make storage work more efficiently for these new applications. And all of this of course in software so they need that capability to develop storage at the speed that they do about their software and their applications. The hyperscale or the cloud data center of course is built on being software defined. They've had tremendous success in moving to a software defined networking approach. The computation is there software defined hardware is there they're starting to see a lot of use cases for FPGAs in hardware definitions. There's even software defined storage layers out there taking all flash arrays and delivering service approaches at the storage layer. What's missing, we have this lower layer of storage mechanism the drive itself. And what about the flash, why isn't that software defined yet. And that brings us to the talk for today's presentation. What if flash was software defined. And we have to ask ourselves, what would we need to do to make flash storage software defined. So let's explore that a little bit. First let's look at some of the challenges that the industry needs to solve the industry we talked to a lot of the hyperscale customers and we've been able to gather information from a wide range of them about what it is they're looking to do and how they look to accomplish it. So, they're looking for data placement. They know their data they know their applications they know how they want to store the data so they want to be able to have finite control over where and how they store their data. At the same time, they're in complete control of their workloads, and they know their tenants and how to isolate the workloads from one tenant from another, they're avoiding any cross pollination of IO, noisy neighbor syndromes. And they want to be able to control latency, they want to handle how fast they can get to that IO and control that so they can deliver quality of service to each of their customers or each of their applications. So we all know workloads adapt and change over time so they want to be able to adapt to new workloads on the fly as those workloads change. On the other side of this slide we're talking about a couple of other things that have to do with the hardware itself over provisioning at scale. Inside of our laptops we over provision and we raid the flash die inside that SSD. It's a single device. We want your data to be as safe as possible. And we want it to work at its most optimum speed so we over provision and we add rage the flash die. What this means is we're reserving several bites out of that available flash in order to handle that over provisioning and that rate function. The hyperscale data center, typically they're going to want to have access to every bite of flash, because they're handling data integrity at a higher level they're handling it at the rack level not at the individual device level power loss protection circuits we put that in every SSD as well. Although most data centers, they had power loss protection or battery backup at the rack level so power loss protection in an individual device is probably overkill. So a software defined approach can help solve some of these industry problems, especially the workload tenant and workload problems. So look at these problems and say okay how can we solve these. Well, the first method that we need to look at is, we probably need to abstract the flash with a software based programmers interface and API. Now this API would have to handle a number of key aspects that would include how do you handle the low level flash itself. There's flash programming in terms of voltages and timing. There's ECC there's dealing with bad pages and bad blocks of data. The API would also need to look at the differences between different types or generations of flash and abstract that as well as differences in vendors flash and handle that through abstraction as well. Hardware isolation, all the way down to the flash die level would be the ability to solve that noisy neighbor issue that I described earlier. Which is important. How do we make sure that the software and the application has discrete control over that workload, so you don't get any performance lags. And then another aspect is that host and that server CPU is there to do applications functions. So is there a way API to abstract the flash in such a way that it doesn't become a burden on those resources reduce the number of host CPU cycles that need to be done for certain features like garbage collection or where level. The next question that we would ask ourselves is, if we were able to do a software defined flash approach, what benefits could be derived from doing so, is there a valuable service that can be performed by going software defined. The answer is pretty clearly yes. Today, you have to buy different types of flash devices to serve different purposes in the data center fast one slow ones, cold data storage hot data storage, all come with different attributes. In this case with a software defined flash approach, you can deliver a single adaptable flash device that can then be repurposed for different use cases. We're focused on all those low level flash problems like programming, erasing and ecc and error management. And through software, it could easily be adapted to new level, high level requirements at the post change the protocol that the device works so it can be used for different use cases or data types hot data or cold data. We want to be able to reuse large amounts of code that we've deployed for each of these flash devices, as well as bringing through that code reuse faster internal development cycles, as well as simplifying the maintenance of the flash devices themselves. So if we look at this and we say okay what do we really need. We need to bring the speed and flexibility of flash, how do we get that maximum potential out of the flash itself. And we need to combine that with the ease of software definability. How do we get all the benefits that flash as a digital storage media brings us without all the traditional overhead of the HDD paradigm. Well, I'm actually privileged in my job here at the Oxy America to work with a very large group of smart and creative engineers, both here in the US and in Japan. But rather than just bring you all the challenges and the problems I'd like to also suggest a solution. There is a software defined flash API available. That's called software enabled flash software enabled flash is a new approach that's designed to bring flash storage innovation to you the developer. It's a powerful way forward for flash to be deployed in data center and emerging storage applications. So we really shed the legacy HDD paradigm. We'll allow flash to behave like flash, which then allows us to bring that flash forward to behave in much more predictable and uniform manners that can also give you the ability to define better latency outcomes for your application. And flash can be used at its native speed software enabled flash brings that software flexibility and that scalability you need in the data center to you the storage developer. It's really a powerful way forward. So what is software enabled flash in reality. At a high level, it's really about the hardware and the software working together seamlessly. So let's look at the hardware portion of this briefly and say, on the left of this slide you can see a hardware block diagram. And in this case this is a purpose built media centric flash controllers specific to deploying flash using the software enabled flash API. It handles all of the low level tasks of managing the flash itself flash page programming timings and voltages that are required handles the health of each individual flash cell brings forward the use of ecc and defect management within the flash controller. We've seen from some of our customers different and varying needs for how they use DRAM in the device so it can deploy DRAM on the device, or you can reduce the amount of DRAM and or completely eliminate the use of DRAM on the device itself. One other thing I'd like to highlight. We of course being Kyoksia we deploy our flash using a flash interface known as the toggle toggle mode interface. In order to make this controller capable of using different types of flash, simply go in and change the flash level interface to whatever is necessary to deploy the next type of flash. It's a fairly easy and straightforward process you can change that toggle mode out, employ the ONFI or on fee mode, and a different vendor could also be used deploying software enabled flash for your use cases, a multi vendor approach. So if we change the approach and start looking at the software side of this software and hardware working together, the software stack is shown here on the right. Of course, we have a device driver that talks to the hardware and the controller itself to bring that flash forward. We have a software enabled flash API that comes forward in a library that gives access to the flash, either through the file system and the traditional of block level drivers and reference FTLs of the operating system. We have sample source code that shows how to implement that. The hyperscaler, the cloud customers also have defined their own approaches to this file system and operating system stack. So it's very easy to take the SEO, the software enable flash library and apply it to those custom software defined storage stacks. But what I'd like to highlight really quickly if I can is notice that the library, this section in blue actually runs all the way up to the user application. You can use flash native semantics through the software enabled flash API and library to talk directly to the flash device by bypassing the traditional file systems in your OS. And to demonstrate this, we do have a couple of interesting applications that use this flash native approach. We have a version of rocks DB that talks flash native through the software enabled flash API. We've got a version of firecracker for virtualization that also talks directly to flash in the flash native mode. And for testing purposes we took the IO generator known as FIO and adapted that to the flash native API approach as well. Now, all of this software aspects that I've talked about are going to be available through open source, the API and the libraries are already up and available in open source. Later this year we'll be bringing out all of the sample source codes in the form of an SDK, and they use those will also be available on open source. So bear with me I'll talk a little bit about the open source strategy at the end of the presentation. But let's take a look at the programming capability. There's a wide range. And again on sample source code is available of different aspects of enabling and deploying software enabled flash. So anything from a CLI that allows a host to automate and batch file up the creation of virtual flash devices using the SCF API, all the way through data handling commands and event handlers, as well as our data path commands have a certain range as well. So a pretty flexible library. Now, talking about programming and source code via PowerPoint is probably not the most exciting thing I myself can be doing there's some really smart people that could probably make that interesting, but I don't think I can. So what I'd like to do is change the approach and not talk so much about what the source code looks like, but about how do you use it. How do you actually turn on and enable and deploy software enabled flash capabilities. I'd like to do this through some demonstrations. First we'll talk about how you define a software enabled flash device data placement and workload isolation will be a big part of that definition. And talk about how we can deploy different protocols on different applications on the already defined and isolated flash device. After that we'll talk a little bit about latency and how you can control latency all the way down to the individual IO level using advanced queuing methodologies built into the API, as well as we'll do a quick demonstration on how we can offload those host CPU resources for better program efficiency in the hardware. So let's move forward and let's talk about how do we define a software enabled to flash device and how do we use that definition to isolate workloads from each other. So the first thing we need to do, you can see on the animation that I have here, a typical layout for flash controller and flash die we've got eight channels with four flash diaper channel. And that would be let's isolate hardware all the way down to the flash die level. In this case, isolation by flash die is done by what we call defining a virtual device through the API. In this case we'll take blocks of different blocks of flash die and create virtual devices so you can see in blue virtual device zero in red virtual device one and in green virtual device to create layouts different numbers of flash die but very easily to define completely isolated zones of flash. Now on top of these virtual devices, we can layer a second layer of isolation through software what we call a quality of service domain. So this software layer allows us to define different protocols that we want to deploy in each of these domains. We can control latencies and different operations through these software isolated zones quality of service domains. Now that we've defined a device, the real purpose for having storage is to be able to run applications and store data. But every application and every device needs to run in a slightly different manner depending on your workload. So let's take a look at how we can deploy different types of protocols on these defined locations within this flash device. So let's start by deploying a typical web style application. And of course, let's start with the simplest mode which would be a traditional block motor or a typical solid state described type of operation. In this case so we can show the isolation activity, we're going to run this with a mixed read and write IO pattern for QoS domain to let's bring in a different app will bring in a streaming app. And it's important for us to show that you can customize how you use and deploy your protocols so we're going to run this using a custom FTL capability, a completely custom written protocol for deploying storage like a drive. In the third zone will run yet a third app and a third protocol will run a database style app. So the streaming app will do 100% read IO and this data base application running in ZNS mode will run with a 100% write IO pattern. Now notice, as I've done this, I have left in the layout definition open die that are unused. So if you get to running the demonstration will show you that we are truly isolated in our working zones. So let's move forward and show you the actual demonstration running on actual flash and hardware. This is a paused image of a running demonstration. And if you oops, let me get going here so you can see I've got my three separated zones going. The first is that block mode running in a mixed read by IO up in the upper side of the custom FTL mode running 100% read IO read is blue right is orange. And then the third zone of course is running that ZNS protocol with a 100% right. Now it's important to highlight that because we need to be able to prove to you that the IO is running independently of each other, and they're not interfering with each other. And to highlight from this layout, you can still see the flash died that have not been selected for use in this demonstration. So let me kick off the IO that's occurring. And you can see we are completely isolated from zone to zone, the IO's are not interfering with each other the tenants are completely isolated by workload rewrite in the first zone 100% read in the second zone and 100% right in the third zone. So this is a combination of IO. You can imagine with the parallelism of flash, each of these zones are running independent of each other. The tenants are not being noisy neighbors to each other and they're all running at the full speed, full set the parallelism of flash can bring. Now, one of the highlight. And this is the normal mode for running a single flash device in a rack environment, you're going to be running hundreds of devices. And they're all going to be set up in individual zones with different softwares on top of them. What this does demonstrate for you though is those different protocols can be applied and changed at workload changes in your working environment. You can change the status case storage go in and change the software driver and you can change from a typical block mode to a custom FTL mode or to a ZNM depending on the requirements of your workload. Okay, I think the next portion of our talk was going to show you how we can manage late the device level. Now, latencies come in all sorts of different forms for SSDs. There's a very high performance latency approach that unfortunately has a few outliers that can slow down the average latency. Approach is let's not necessarily run the flash at the fastest possible speed, but let's make sure that we have a consistent latency with no outliers. To look at both of these profiles, we have the same average latency between the two, but there's a different performance profile expected from these. And some people may ask which one is better. Now my chief architect likes to say this is a trick question. And it's a trick question is, because the answer is it depends. It depends on the application that's being used or deployed and how it needs to run its IO. The good news is with the software enabled flash API and technology, it gives you the programmer, the ability to control your latency outcomes as your application requires it and change those outcomes on the fly. Next to the software enabled flash API are three different queuing modes or protocols. First is a priority queue methodology. Another one is a round robin queuing mode. And the third one is a very powerful die time weighted fair queuing mode.  This ensures that your IO is prioritized fairly based on your users needs, you can avoid IO starvation problems all under application control. So let's get back to our animation and let's highlight that first zone where we put up to queue us domains within a single hardware device. We're going to run two different identical read workloads in both of those zones. And then we'll show you how you can adjust on the fly using software to control your latency outcomes. For zone one and zone two I have two identical sorry about that to identical read weights defined, and you can see the latency in the chart. They're both roughly equal, they're slightly offset roughly equal. Now through software we can go in and change what we expect in terms of weight for each of those zones and you can see in real time. The latency profile changes on the IO in process, we can flip it around. We can change it again and continue to give more priority to zone one the red line. This shows you that you have direct finite control over latency for every IO and workload going on and that control is accessible to you in real time through software. This is a very powerful feature of the software defined flash API. All right, the next demo. The last demo that we have to show you is the discussion on how we can offload the host resources. So the host can concentrate on doing host things running your applications, without having to worry about how to deal with low level housekeeping functions down at the flash device level. We need to reduce that impact on the data management of the flash so the host CPU and memory can go off and do the things that he needs to be doing to run the application. In this case we're going to run a garbage collections, a garbage collection example. This would also work equally well for things like where leveling or for an application level database compaction style operation. The first example of course is if we were to do all of the garbage collection activity manually, we would have to go out and identify and read in all of the data that we need to recover, collate that and write that back up to the flash device, which then allows us to go up and free up those blocks for more writing. In this case it of course takes host commands read commands write commands as well as use of host DRAM. Now a feature built into the API is something we call Nameless Copy, which is a copy offload feature. This allows us allows the host to send a single command identifying what data needs to be collected, and the device itself can go read all of that data collate and store it into flash blocks without using any additional host resources or overhead. As you can see from the animation we've reduced a set of 20 commands down to one command. This reduces that burden on the host CPU reduces the burden on the host for memory buffering, as well as reduces that PCIe bus and BME bus bandwidth. And we have a functional demonstration for you here as well running on actual hardware. So of course we have the manual copy on the left and the Nameless Copy on the right. We're going to run to identical right workloads 100% right workloads. And the workload is going to be larger than the available storage space in each of these two zones. This will force us into a mode where we have to do garbage collection to finish the workload that's been defined.  Red of course is the right workload blue is the copy activity. And you can see there's no copy activity on the Nameless site because we're not actually moving data in and out of the host, but the host of course is having to read and then rewrite data to free up that space for the next right operation. So the manual copy operation is already completed. This test normally takes about three minutes so we've accelerated it quite significantly. Now the manual copy operation has completed. You can see that we've done a fair amount of reading and writing to move data. The results here are for the manual copy operation to complete this workload we've issued 800,000 commands and moved about three gigabytes worth of data to do this garbage collection operation. For the Nameless Copy Copy Copy offload operation, we've issued only 24 commands to do the same workload identical workload. And those 24 commands used up only 128 K of data across the bus. And if you look at the CPU utilization chart that Nameless Copy operation has done so without using so many host CPU cycles. So again, copy offload capability built into the software enabled flash API gives you tremendous capabilities to reduce host overhead for things like garbage collection, where leveling, and even application layer database level compaction There's actually quite a bit more to software enabled flash that I've been able to show you in this simple set of demonstrations. Very powerful capabilities built into the definition to handle almost every aspect of flash management and IO expectations that can come from any developer. What I would like to highlight is item number seven again, and talk a little bit about the abstraction of those flash generations, the ability to change from flash generation flash generation whether using a TLC media, or a QLC media whether using a gen four gen five or a gen six from the fan is a very important capability abstraction through the API allows us to deliver different types of flash as well as different vendors to deliver flash to the API. So you the programmer don't have to worry about those low low level differences. So that API abstraction can bring a bunch of very good benefits right software enabled flash technology is a software defined a flash approach, and that abstraction can give you a tremendous advantage in your development activities for time to market. Bring your next level of flash to market extremely rapidly without having to deal with a lot of overhead programming activities. Your resources, your resource allocation, which is your human resources can be used very efficiently. Those programmers those developers those resources can be focused on development where it matters most at the application layer, without having to deal with low level flash semantics, or changes to programming required to deploy that next generation flash. The only way is utilize and maximize the flash that you've acquired to this utmost capability. Remember, as your workloads change you can change the protocols on that flash device simply by going in and changing a software driver. You get a whole new use case for your flat through changing software. I actually fundamentally believe that software enabled flash completely redefines that relationship between the host and its solid state storage. Now I didn't mention I would talk a little bit more about the open source aspects of the API. We have available today out on GitHub. The API document itself all of the command sets are exposed already, as well as a header file showing how the command sets are going to be implemented. The API document and header file are out and available using the BSD three clause open source license. I invite everybody to go download these files and take a look at them and see how they go. Now we also know that in order for open source to work it has to be open, it has to be available, and it has to be neutral, and we of course know that we're going to need multiple vendors and multiple sources of flash. We're currently out working with the Linux community to create a project in the open source community for software enabled flash. We need this open and legally neutral forum to bring the talking technology forward. So the industry and vendors club competitors can work together to make this available to you the user. The project this community based product project will be available and out in open source in the second half of this year. And all of the sample source codes for the libraries and the drivers and the software development kit will be made available through this open source project when it is turned on. So I'd like to thank everybody for attending this webinar session. For additional information on what software enabled flash is I'd like to highlight that there is a website available with lots of useful information software enabled flash calm. There's white papers there's tech breeze. There's a lot more videos on the functionality and the capability and demonstrations of how the hardware actually works. And upon the website is also a link to the API. Thank you for sticking with me through this presentation in this webinar, and we have some time left. So I would like to open up the session for q&a. And in order to do it. Well, would like to invite my lead architect for software enabled flash to join me worry bolt worry bolt if you can unmute and come online and join me that would be fantastic. Hello Scott, and happy to answer any questions that we can in the remaining time. Okay. So we've got an anonymous question here that says to adapt this API do we need a device with some special capability, a device that exposes fine level control over device resources. And yes, in fact, software enabled flash is in fact a combination of both the software libraries and API is that we're defining as well as a new class of controllers which are not available yet but are currently under development. The good news is that that the plan is to have the software enabled flash devices available for multiple vendors. So you will have your choice of who you would like to buy this technology from. But you will require a new class of device to enjoy these benefits because, frankly, they allow capabilities that existing SSDs literally cannot do. Thank you, Rory. There's actually another question from Michael. He's asking about the relationship with rocks DB. He's asking is it just a library that uses flash or is, or is it using the API is that we've created. So with respect to the rocks DB example, we've actually taken a branch off the main rocks DB repository, and we have reworked rocks DB to talk directly and natively to the stuff API. In particular to take advantage of some huge gains that can be made in compaction and once again that source code branch is not available yet but will be it's planned to be published with with the actual SDK itself. Okay. Thank you. Another question has popped up from a Raj. He's asked, how does the abstraction work, how can we abstract different PCI generations gen four or five, or differentiating the NAND. How does that actually work. And further, how does the developer leverage that. Okay. Sorry, things are scrolling off the screen here. So that I can't see that question. Let me see. I want to make sure I, I address it correctly here. So the actual abstraction of differences, such as PCI gen four versus gen five. And because we will have classes of controllers that implement the specific different hardware standards, but all comply to the same software API so you write your software to the common API and then, depending upon the capabilities of the device, it will work with a variety of devices that applies to both PCI generations as well as flash generations. Okay, let's move on to another question. They're asking, is this, is there a flash emulator. This is an anonymous question, but is there a flash emulator that can be used to this class of device. Currently, there is an emulator that we are using in house as we're developing the hardware and so that's very common because software usually leads the hardware in terms of delivery. We do not know at this time whether or not we will be commercializing or commercialize by the wrong wrong word. Don't know if we'll be releasing the emulator or not. Yeah, I think we will have actual devices within this year so an emulator may not be necessary. Right. Yeah. Okay, another question also anonymous is, is this different or how is this different from SPDK. SPDK is a wonderful package from from Intel but SPDK is concerned primarily with traditional storage devices so SPDK back ends to classic HDDs or SSDs, whatever your storage is, and allows you to layer functionality on top of that but fundamentally you're going to be limited by the capabilities of the back end store and so for the types of advanced latency queuing outcomes that we want to provide you actually need a new class of hardware. Great. Let's see packaging hardware I think we've answered there should be hardware available by the end of this year. So it goes to be connected directly via PCIe or something that goes into a box that's accessed over a Sam. So, the answer is, it depends on that one so it is in fact, at its core a PCIe device that can be accessed directly over PCIe, or could actually be used as a internal component if you were building some type of of external type of box, or NVMeoF type box. So, you know, for a typical hyperscale application, they tend to use direct attached storage and would be accessing it directly over the PCIe bus, but there are storage vendors that produce external aggregations of storage if you will, that are also interested in this technology. Great. So, there are no more open questions at the moment. I would like to thank everybody that has joined the webinar. If more questions pop up, we'll go ahead and answer those before we sign off. But as Roy has identified this is a very interesting and new approach to using flash as flash itself rather than from the HDD paradigm. It's available and out in open source for any storage developer. I guess we do have a new question. How do you foresee this class of hardware to work with NVMe over fabric? Actually, I think it's going to work fairly transparently with NVMeoF. The first version of the API is dealing with direct attach. However, it's my personal belief, so don't construe this as any sort of product commitment, but it's my personal belief that the logical next step for this is dealing with aggregations of these devices in a networked environment. And of course, NVMeoF would be the logical choice for that. So, I'll take that as a very leading question and I gave you a very leading answer, albeit a personal opinion. Thank you, Roy. You know, I think we always envisioned the software enabled flash approach both the hardware and the software to be a building block for delivering larger and better storage type of devices. So as a building block we can deliver a traditional SSD or something completely custom, or as you've identified a NVMe over fabric approach as well. Here's a question from Jan asking if it can implement a key value store. I can go ahead and answer this one. Of course, it's all driven by software. A software driver can be put in place that would allow that key value store to be deployed as a protocol. If you think about it, that key value store could benefit tremendously from those host offload functions, imagine a key move function being done wholly within the device using that copy offload feature. Roy, do you want to expand on that? Hi, I think that's a good start. Key value stores are actually something that that we have considered from actually inception. And there are a number of possibilities. I know that that there are some internal Skunkworks projects within Kyokusha to develop a key value store that may in fact end up as an example in the SDK itself. Great. I think with that we're running low on time, and we are out of questions at this point as well. So, I'd like to pass it back to Christine on the Linux foundation for any closing activity that we need to do for housekeeping. Once again, thank you everybody for joining us. Please feel free to reach out to us with any questions that you may have. We love to pick up questions you can do that. Either through the GitHub site or through contacts available to you from the software enable flash dot com website. Once again, thank you very much. This is Scott Stetzer signing off. Thank you so much to Scott for his time today and thank you to all the participants who joined us. And as a reminder, this recording will be on the Linux foundation YouTube page later today. And we hope that you're able to join us for future webinars. Have a wonderful day. Thank you everybody.


Hi and welcome to our Kickstarter Discover Hungarian Wine a visitor friendly guide I want to give you a little bit of update We just launched and at our launch day. I'm actually out visiting vineyards and tasting in Hungary I'm in the wide region of Nesmee. It's a really small region of northern Hungary I'm in the village of let me see if I get this right Castots at Sivek winery small villages and regions like this in Hungary or what makes it such a charming country to visit It's really the country's really dominated by a lot of small producers I just want to let you guys know everything's live the first five days of the campaign you can get a 30% discount if you pre-order a special edition signed copy of Discover Hungarian Wine It's gonna be in full color the special editions are only available during this Kickstarter There's also some wonderful live experiences that you can get including a day trip to Tokai dinner with us in Hungary even have us speaking at your corporation or tasting group and As the campaign goes along we might roll out some other live experiences So check them out supplies are limited and follow our thread. There'll be lots of updates No learn a ton about Hungarian wine. I'll see you soon


I want to say good evening to everybody. Welcome to the West Cliff drainage sewer and water improvements project public meeting. Just a really a quick, a few quick notes. One is that we are going to be, we are recording this meeting and after the meeting is over, we are going to post it on the city website so we could be listened to later. Everyone is going to be started off as muted and also the videos are going to be turned off. Our goal is to keep an orderly meeting and with this being a WebEx meeting, we just felt that was the best way to keep control of the meeting is to start everybody off as being muted. At the end of the meeting, we'll be taking questions and so at that point in time, we can start unmuting people. The, for those that have, that are online, if you would, there's a, on this slide, you'll notice there is a chat button next to the, I guess it's highlighted in blue and if you would type your questions in that, if you are on via phone, then that's gonna be a little more challenging for us but at the end, we'll unmute the phones of people that are online and we'll do our best to take questions from the college. See, my name is Mike Bennett. I am the project manager for the West Cliff project. I do have an assistant project manager, Dylan Johns, who is going to take you through the slideshow and presentation. At the end of it, again, we will come back and respond to questions. Dylan, do you wanna take over? Yeah, we'll go ahead and get the presentation started. So Mike has already introduced us. I'm the assistant project manager for the West Cliff drainage and sanitary sewer project. To go ahead and jump right into it, a little bit of background on why we're doing this project. We have had some issues with flooding in this area, as you can see in the picture on the left there that was taken on June 28th, 2004. The flooding is in part due to undersized drainage pipes and that's what the stormwater aspect of this project that we plan to address. And since this is a combined project with stormwater, water and sanitary sewer, the water pipes and sanitary sewer pipes are outdated and undersized and due for rehabilitation or replacement. This phase of the project will be the final phase of a multi-phase project. So this should be it, you know, related to this project in the neighborhood. A little bit of a project overview right here, these are all the streets we will be working on. There is stormwater work on Suffolk Drive that is highlighted in red, if you can see the map. There's also gonna be stormwater on Anita Avenue, Manderley Place and Trail Lake Drive. Everything in blue and green is going to be water and sanitary sewer, respectively. There is some water on Suffolk Drive, Manderley Place and Trail Lake Drive, as well as Seminary Drive, Anita Avenue and Winfield Avenue. We are also doing sanitary sewer work on Manderley Place, Anita Avenue, Winfield Avenue, South Drive and Seminary Drive. Here's our overview of the project for the stormwater portion. The different phases are highlighted, as you can see, this phase that we're working on right now is phase one. Phase two A has already been constructed, it's complete and in the ground. Phase two B is currently under construction. So some more information on project details. This is just kind of reiterating what was on the map two slides before. The stormwater aspect is upsizing the existing storm drain system on Trail Lake Drive, Manderley Place, Anita Avenue and Suffolk Drive. The waterline upsizing is happening on Seminary Drive, Anita Avenue and Winfield Avenue and then the sanitary sewer work is happening on Trail Lake Drive, Seminary Drive, South Drive, Anita Avenue, Winfield Avenue and Carolyn Road. One part of this that we wanted to highlight was the outfall of the stormwater project. We will be out, the new storm drain pipe will outfall into the existing channel along Trail Lake Drive in between Incanto and Wendale. We will be adding a significantly larger pipe. If you can see the screen on the bottom left of that detail, you can see that new large box there on the left that I'm kind of circling with my mouse cursor is the new pipe that we will be installing. This arch pipe here on the right is the existing pipe, which will also be remaining in place. To help protect the channel banks from erosion, we plan to install a large rock riprap in the channel there at the outfall. The area where the riprap will be installed is this area that I'm circling with my mouse right here. It's outlined in black. And the large rock riprap, as I said, is just to protect the channel banks from erosion and dissipate the energy from the water with the new larger pipe that will be outfalling there. So the current status of the project, we are still under design. We have completed our 90% design. So we are almost finished with that phase of the project. We are scheduled to finish our design in August, so next month. And then we plan to begin construction in the first quarter of 2021, which would be January to March. And we expect construction to last about 18 months. So that would put us finishing construction during the summer of 2022. A little bit of road closure information for this project. There will be some partial and full road closures. They will all be temporary. So they will only last for the duration of construction. And those closures will be happening on every street that is affected by construction. So all of those streets that I named previously. And all residents who will be affected by those road closures will receive advanced notice with all the details that will be relevant to the road closure information about when to expect it, how long it will last and all of those things. So now I guess we will open up to questions unless Mike, you had something else that you wanted to add. I do wanna add one little thanks. We did have a couple of participants join in a little bit after we got started. So I do wanna hit on a couple of the initial statements. Number one is the fact that we are recording tonight's meeting. So if you miss the first little bit, we will get that information out to the residents and we posted on the city website and we will help get that address to you so you can catch some of that original, that first material if you came in late. I also wanna acknowledge Council Member Ann Zeta has joined the meeting. So I just wanna make sure that people are aware of that. Again, my name is Mike Bennett. I am the project manager for the project. The Dillon Johns is the assistant project. He just took you through the slideshow. So hopefully that catches some of the people, I think that came in a little bit after our first couple of slides. At this point in time, we've got quite a few participants on here. Now everybody is muted. And there are, let me see here, we go through the chat, see if anybody has posted any chat. See, yes, all right. So wanna make something clear here because one of our communications guy caught something that may have not come off right. As far as any temporary closures, it did kind of sound like we were saying they're gonna be closed for the length of the project. That's not what is happening. We will have temporary closures that will occur for short durations of time. There will no, not one single road will be closed for the entirety of the project. There will, the closures will be, will occur, there will be a closure and then it'll be open during the project. So of course, at this point in time, we cannot state exactly what those dates are that will be developed as we have the contractor on board and as the contractor makes his plan for constructing the project. Let's see, how is the sewage replacement parallel to self drive, not in the street? All right, so we have a question from Ms. Sally McCoy. How is a sewer sewage replacement parallel to self out drive but not in the street going to be accessed? Dylan, can you bring up the drawing that shows the different sewer and zoom in there? Yes, sir, good job. See, Sally, I believe if you're talking about something that is off the street, that you would be referencing this piece of sewer between the Avenue and Trail Lake Drive just north of Suffolk. Okay, yes, I see your chat there. So that sewer replacement will be done. There's currently a sewer line back there. However, I do believe that that kind of replacement will be done through trenchless methods. They will not be digging up the entire length of pipe. They will access it from the ends and basically run a new pipe inside of the old one. Mike, I don't know, can you help us a little bit? Absolutely, Dylan is correct. The backyards, they are a little bit more challenging for the city. There's a lot of times, what happens is we try and move those to the front yards and into the street when that is a possibility. That is not always a possibility. So when we have them in the backyards, we do a trenchless method. Now then that does not cover the services. So the contractor will have to dig up and reconnect the services to that line. The contractor will get with the residents prior to this work starting. So the contractors are really good. They've been doing this for a while. So they'll get with the residents to let them know when it's happening and how exactly it will affect you. I'm hoping that will answer your question. If not, please let us know if there's some additional questions that you might have. Okay, great. Now we also have a question from a, I think that's Carol or Carol Way, the short answer segment sewer between Porto and soulful properties entails what exactly will you be tearing up our yards? How will you access that work? I believe, is that the same segment, I think, Dylan? I believe so, but I don't know if Porto is the street immediately to the north of here or not. All right, I've got a, hang on, yes it is. I've got a map up on my computer. Yes, that is. So hopefully that answered that question, please. Carol Way, if you have an additional question, please type it because we are getting your question. See here, does anybody else using the chat function have any, okay, great. Looks like we got that one. Does, is there anybody else on the computer not seeing anything? So now then, I guess the next, say, okay, here we go from Chuck Nixon, will sewer and backyard be abandoned? All right, so that would be, there are, Dylan, correct me if I'm wrong, there was, the water department does have some sewer in their back and a couple of these backyards that they're moving to the front, correct? And therefore, if we are moving the sewer from the backyard to the front, any sewer in the backyard, yes, would be abandoned. Dylan, we do have one of those, correct? Yes, we have at least one. I know that there is a sewer line right here to the west of Anita, that they are moving into the street. And then I think there is one on the north of Sydney that's moving into the street. Those are the only two I'm aware of. Those are the ones that I felt were in there as well. So the question, the answer would be yes, it would be abandoned. We do not leave the manholes in the yards of what manholes would be removed. Let's see, what are parking option situations during this project? That is, okay, so what are parking option situations during this project? That is a really, really good question, because I know there's, that's gonna be impacted twice for many people. And the two times it'll be when, first time will be when the utilities are being installed, especially along the storm drain route, because they're typically what is, what I've seen, how the contractors have worked, they've got one excavator that digs a hole, then they have another excavator that puts the storm drain pipe into the hole, and then once it puts it into the hole, it covers the hole up. So you have two of those things working back to back in a hole that basically moves along the path of the storm drain line, and it's kind of like a little bitty train. And that train can be about 50 feet long, and during when they are next to your house, there will be no entrance and exit at that time. Now that they move very quickly, so the contractors are really good at this, and they're also really good at notifying you when this will, when that will happen, when they will be in front of your house, and there will be a challenge to the driveway. The other time that it happens is when the asphalt streets are redone, because these are asphalt streets, and after all the utilities are complete, we will come back and install the redo the paving. And of course, there is a couple hours there where the contractor will need, let everybody know that you shouldn't be driving on the pavement while he's doing that work. So the contractors again, will provide notification that this has occurred to help you get out of the, get your car out of the driveway in place where it needs to be, so you can go about your business and not be stuck in essence. See here, hopefully that answers that. Let me see, we're getting, all right. So we're really getting some good questions here. I'll make sure I gotta scroll up so I capture all of these. I really don't wanna miss anything. So we see it goes over, we're parking options. Okay. Do we have timing for any of these changes yet? Do we have timing? I guess I'm not understanding that question. Mike, if that is a question about when we plan to start construction, we plan to start construction in January to March of 2021. And it'll take about 18 months. I'm not sure if that's what you're asking or not. So please send a followup if you need a verification on that. Mr. Hughes, yes, please. Mr. Hughes, that was, if you could follow up with that. Let's see, when the sewer has moved from the rear of the property to the front, what is the process for connecting the house to the new service? Basically it's on the contractors to make that connection. We do not put that onto the residents. So again, the contractor will be knocking on your door and getting with you on the timing of that when they, and they will work from the back of your property and align it and get it moved to the front. It's all on them, they will do their best to make it as least intrusive as possible. But of course, just depending on the situation, there's a lot of different things that could come up. But it is on the contractor to make that connection. Please let me know if you have any additional questions on that, I think that was Ms. Garnett, let's see. Okay, let me see. Next one for Mr. Nixon. I want to note a concern I have raised directly to the city staff. I am concerned about a major outfall of water directly adjacent to public walk, bike path. I have requested staff consider mitigation, also a concern regarding the aesthetics of the outfall to ensure we don't have a project that looks out of place in a residential neighborhood. I want to be sure the council member Zeta is aware of this concern. Absolutely, Mr. Nixon, you're not the only one asking this question. So this is something that we are taking a strong look at. Our desire is not to come in and create an eyesore. That is not our goal. Our goal is to reduce flooding risk but also make sure that we do our best to maintain the aesthetic and context that is there. So we are working right now to see our design is not complete. So we are working with residents that are just adjacent to the channel to get their opinions on it. And we're certainly willing to listen to anybody that has an opinion on it. It is the drainage that we are working with. It is not, we're not putting new flow in this basin. This is water that was getting there initially. It's just the fact that it was previously backing up into lots and into streets. And so our goal is to get it to the creek more efficiently. So it's not that the creek is receiving any more water. I also wanna note that our team is working with the floodplain development group that maintains the floodplain information for the city to make sure that we are not negatively impacting or doing anything that we shouldn't be doing in this floodplain area. We're also coordinating with parks because this area that we're outfalling into is their park property. So we're also coordinating with the park property. Our goal and the outfall is to make it as natural as possible. What we're talking about as far as the rip wrap is basically our goal right now or one of the things we're looking at is what we refer to as loose rock rip wraps was just large rock placed within the channel that acts as a way to reduce the energy that's coming out of those storm grain pipes. And it's goal is to protect the side slope. So there is, it limits the amount of the erosion that will occur. We are looking at, there is a lot of good screening that's already out there naturally and we are not going in there and clear cutting everything. I wanna make sure that that's understood. There's a lot of vegetation that's already there. Our goal is to keep as much there as we possibly can. So that is another thing that we're gonna take a look at and it's also what we're working with parks on to help us know how close to the trees can we get what can these trees withstand when we're going through and putting in the project so they remain healthy after the project. So Mr. Nixon and also I just wanna make sure any kind of follow up Mr. Nixon, please you've got my phone number on the card. So please feel free to reach out to me if you have any additional questions or concerns. Because again, we are doing our best to make sure that we're taking care of everyone in this. See, so let me know if you have any additional questions on that. See another next question, does Manderley plays get the full double rectangular storm sewer in the middle of the street along with the sewer and water. So Manderley is going to be a very, very challenging and project for the contractor. There's already a lot of utilities that are there and the short answer is yes, we are putting a big rectangular storm drain box in Manderley and right now where the water and sewer are located they're currently in conflict they're in the way of our storm drain box. So we are going to have to relocate that and it's gonna be a fun project for the contractor to be sure. But this is also something that is done all the time. So the short answer is yes and we will be working all that out. Please, I guess let me know if you have any more questions on that. I see the next question here. When will they be on Carolyn Road? Dylan, can you identify? Carolyn Road is gonna be this one right here. Engineer chimed in said Manderley gets a single box, not double. All right, that is, okay, let me see, perhaps my, okay, the full double, I'm sorry, I apologize, I did not read that question thoroughly. No, it's not gonna get, the double box is down there at the very end where there's only a single box that's gonna be going down Manderley Road. I apologize for not being clear on that. Good. So on Carolyn Road, we do not have an exact timing on any of the streets as far as when the construction, that will be the contractor's responsibility to determine when, based on the crews that he has and the construction that needs to take place. Now then, once we have the pre, after the pre-construction meeting, once the contractor puts his schedule together, we will have it at that time. So we will have another meeting prior to construction. The typical meeting is the pre, for the residents, there is a pre-construction meeting that we hold. And at that time, the contractor may not have his exact schedule at that time, but he will be working on it and may, depending on the contractor, he may have an idea when he's gonna work on it. Now then, with that said, this is an 18 month project. And so we just all have to understand, based on rain, based on just how the world is working right now, we've got to just all be prepared for some plans to change. So even if he had a schedule, even if he has a schedule at the pre-construction meeting, it is entirely possible that that schedule could change based on the events and that are happening at the time. But what I will say, the most important thing I'm hoping that you guys get is the fact that we have an open line of communication. You have my number, our goal is to notify you guys as we have construction going on and notify you before it directly impacts you. So that's gonna how we're gonna treat that. So but also please ask questions if in contact me, if you have any additional questions. Let's see. All right, I guess, let's see, let's know we will have a pre-construction meeting for specific questions. All right, let them know, we will have a pre-construction meeting for more specific questions. That is correct. We are gonna have a pre-construction meeting. The name person's name is above the comment, not below. So I guess I'm maybe messing that up a little bit. I apologize if I'm giving the wrong, quoting the wrong person as far as a question. And maybe I'll just avoid that to prevent confusion. Let's see here. There's a comment, mandrily gets a single box, not a double box, that is correct. It is a single box. Yes, an additional question. I heard statements reflecting plan to be finalized by August and will that plan be made available to us prior to finalization of the project plan and the commencement of work? We can, we can make that plan. Is that, I think this is doable. Is, I guess my question would be, is this specific to the, the outfall? Is that a lot of this stuff is underground. So I'm assuming that's less of a concern, but obviously we want to take care of. So we can certainly work to provide everybody with the final plan on the outfall. I will say as far as that goes, we, the outfall might continue a little bit past August. My goal is to get this done in August so we can advertise it correctly. But time is a little bit tight. So we're trying to get this that worked out as best we can, but our goal is to get everybody as on board with this as we possibly can. See, next question on here. If our driveway is blocked on average, how long can we expect to wait before we have access to our driveway? That's gonna be, depend a lot of up to the construction that's going on. I can't give a definitive answer on that. I would, I, just from what up my experience on one of the other projects that I had, I would say it was generally no longer than a day. For the paving, it's just a few hours, is the time that you're kind of blocked from your driveway on the storm rain, especially on Manderley, it's gonna be a little bit more challenging because we have the big box and also the water and sewer that we're doing there too. But the goal is gonna be as short a time as possible. In other words, we're not looking to block anybody out for weeks at a time. The goal is a day or less is what we're gonna shoot for. So hopefully that answers your question a little bit. We'll see question specific regarding the outfall. Okay, so that's great. We'll, we will look to try and get everybody that drawing in our plan prior to it being finalized. So you guys get a chance to see what we're doing and what we're proposing. So that is totally, that is definitely something we can do. Let me see, will construction start at Trail Lake or at Grandbury? Great question. So the storm drain aspect of this will start, we always start at the downstream in and work our way up. Well, I should say always. That's the typically how it is done. Now then there are, because we're doing storm drain, water and sewer, sometimes contractors have different crews that have different specialties. And so they could end up working on the sewer and water prior to the storm drain. So again, it will be up to the contractor which provides us his schedule. We'll have a better idea at what roads will be impacted when. And again, we can share that as we get it. Typically though, on the storm drain, we do start on the downstream, which that is at Trail. So we would start at Trail Lake and work our way up to Grandbury Road. See, support what Mike Bennett said about minimizing impact to floodplain modeling of the project indicates that by facilitating flow to the creek, it will slightly reduce the water elevation at the outfall during the regulatory flood event. Also Mike, I'm not sure. Okay, so I guess there's just some modeling. I guess the best way to say that our modeling shows that we are in some ways improving the situation. The short story is we are getting water there a little bit quicker and that can help get the, sometimes it's best just to get the water in and out of a smaller drainage area. It's kind of a little bit technical. If anybody else has any more questions about that, I can do my best to answer. That's getting a little bit more technical. Let me see. There's something at 628, it sounds like I missed, but Karen, I'm not seeing a, on my computer, it's not logging at 628. So I'm just going to ask, okay, see if I can get this manually six. She's a great who asked that question about the aesthetics and outfall of water. Okay, her name above, comment not below. All right. There might be a question out there that I missed that I'm just not seeing. So if there's anybody out there that did post a question, I apologize. Could you re-post it? Cause I'm just not finding the one. Mike, I don't think you answered all the questions I see. Which, okay. Maybe there are some questions that are not coming through on my computer. What can Dylan, can you? No, I said, I think you did answer it. Oh, you think I did? Okay. I don't see. I don't see the question for unanswered. Question. Okay, hold on. Okay. I get, okay. One question I heard statements reflecting a plan to assure a natural look for the outfall. Is that plan part of the plan to be finalized by August? And will that plan be made available to us part of the finalization of the project plan and the commencement of work? Yes, ma'am. That is our goal. One thing that must occur. Cause we have one of the things I need to point out here for stormwater, we have to make a balance. There's a balance that we must reach. One of course is our goal, we do have a desire and regardless of the drainage, I mean, our desire is to bring it back to a natural state. Now then with that said, we have to balance that against the ability to maintain the channel. So we work, our team is the capital delivery team. We work to deliver projects, but we also have a team that maintains the projects that we build and construct. And that team does get a say in what we do. So we have, we are setting up a meeting with our team that maintains the channels to see what we can do to make sure that we are bringing it as close to a natural state as we can, but also such that they can maintain it in a safe manner. So once we have that meeting, we're gonna get back and we'll show that plan and get comments on that. So hopefully that, and yes, the goal will be to have that figured out prior to the end of August. And if it doesn't, we're not gonna say up, we're done. We're moving on. That's not our goal. Our goal is to get this as best, right as best we can. So you can get a bit more detail on the sewer line on Cortot and Suffolk, okay. I guess help me understand a little bit more of the detail. There's, I guess contractors, when they're working on this trenchless method, they dig up on one side and actually dig up on both sides. And they in essence run a pipe through the existing pipe and it's just a replacement of the existing pipe that's there. It expands out a little bit of the internal. And then, but of course, once you do that, you have your services that have been disrupted because of this method and the contractor must go into those yards and dig up those services and make sure they're reconnected. I'm not, is there something more that you're looking at, looking for me to add to that, I guess. I would have, okay, what if that affects the fence? Okay, so that's one of the things the contractor is put on the contractor. We are to replace, make anything equal or better. So if a fence is impacted, we are to go back and fix the fence. And sometimes that means replacing the wood fence, but it's replaced in kind. So that is on the contractor's responsibility. They've got to fix any grass that they disturb or anything in the yard. They disturb, the contractor is responsible for getting it back to the condition it was before they showed up. Not a lot of digging. I guess that can be a relative term. So I want to be cautious there. The goal is to minimize the digging. A lot of that depends on how deep the sewer line is. The deeper the sewer line, the deeper the bigger the hole can get. The other thing to note is how accurate what the contractor does, he does a videotape of the sewer line in order to figure out where those services are. So that, they're getting, technology's getting pretty good. So we're able to find it relatively quick. But of course that is, that also gives a little bit of, there can be a little bit of air in there. So that can help cause them to dig a little bit more than they might want to. But overall they're pretty good at minimizing what they're digging up. And it costs them money if they end up digging up more than they should. So they have an incentive not to, especially since they need to bring it, bring the property back to the way it was or better. See, I have a friend who lives on Anita Avenue. She's completely surrounded by the work. Well, I always be able to get to her house either by coming from Suffolk or from South Winfield. The goal will be, yes, to make sure that you can get to the house from one direction or the other. Now again, when you've got the, I guess the train of excavators and they're digging the hole, again, while that's moving along, you might have to adjust your drive patterns from one side of the other because this is, the streets are pretty tight. It's about 28 feet, the excavator, it, they're about 15 feet wide. And so you're not really able to drive past them on, it's just not safe. On the sewer and water, those are typically on one side of the street or the other. And so that sometimes you can there, but on the storm drain, that's typically in the center and it's going to be in the center a lot of this roadway. And when those excavators are in the center of the road, you're not getting around them so you'll have to go around the other side. But the short answer is yes, you're going to be able to get to the house from one side or the other. Let me see, does that mean you are staying with the original eight inch sewer in the street and putting a smaller pipe inside it? Okay, if it's in the street, we're actually digging up the street. We don't, the trenchless method is a little bit more, it was a bit more expensive than just digging it up. And so anytime that we're digging it up, we are going back with an eight inch. The trenchless method, the diameter, I'm not exactly sure what, sometimes a little bit smaller, sometimes it's equal size, it depends on the method. In the end, no one service is going to be impacted based on us going through there and putting in the new line. This is the ones in the back of the houses, there's not a lot of, it doesn't receive a lot of houses, there's not a lot of houses on it to begin with. So we're not going to put those things, they're not going to be overworked. The eight inch lines can take a lot of sewage. So that should not be a concern. We see with regard to outfall, you seem to be saying there will be a dramatic increase and water flow due to due to the bottling effect, requiring a much larger box culvert. Comments above seem to say water elevation will be reduced. Note today's elevation is six inches, is the water anticipated to be larger flow or not? So let's get a little bit more into the hydraulics of the project. And so there is, it can be a little bit of a tricky, tricky thing to do. See, the one way to say that is there's a, the creek itself, when we do our modeling, it's the 100 year, the 100 year is basically the standard in which we look at a lot of the, we look at the constraints in the model. And on the creek, it's receiving a lot of water from a large area and that can be a bottleneck. And so we've got a smaller drainage basin compared to the, what's already flowing in the Overton Creek. And so the way you look at it is our water gets out prior to the peak in the larger creek getting there. So it's, the end story is when we do the models, it's not, the water surface elevation is not raised. It's not higher than it is today. That's the short answer, and it's due to the peaks. When does the water in the creek, what time does that reach its peak compared to what time does our storm drain system reach its peak? It's most amount of water getting there. Those peaks are not at the same time. So that it's, that's, I'm sorry if that's not super clear, but that's kind of the best way I have to explain that. It's again, it's not that there's any more water getting to this location. It just happens to be getting there a little bit faster. And as far as the timing and the routing method that helps us out, because it's getting in and out of that channel faster than it did before. See, all in our block on Manderley and so forth, the sanitary sewer runs along the rear property line. So does that mean each house now draining to the rear will drain to a new line in the streets? Yes, on Manderley, if it is currently in the back and it's, we're moving it to the front, then yes, you will, we will, our goal is to move it to the front. So folks, make sure it's, well, we're not, no, I'm sorry. On Manderley and so folk, we're just having to, those are being relocated due to the storm drain project. And so we're only relocating those lines from one side of the street, one part of the street into a slightly different location in order to make room for the storm drain. So along, so folk and Manderley know we're not changing the location of the sewer services for those properties. We seem to be out of questions in the chat. I thought we were getting rid of the rear sewer lines, but we're not. He just said, I'm sorry, and he's corrected himself a lot. I know, I know. So I say, we do have a couple of callers. A couple of callers. I've unmuted call in user three. Is there, let me see if there's any other callers. Is there any question that's, questions to the caller and caller three might have that we've not addressed yet. Not hearing anything there to the chat. Let's see. With regard to the outfall, you seem to be saying, okay, on our block on Manderley and so folk. Let's see. Okay. No, I already answered that. That's probably me, Mike. I think I'm the only other caller. Okay. We see. Okay. So. I don't see any new questions. Mike, I think you answered everything that's in the chat. I guess Jeff, Mr. communications man, do you have anything that you want to add to the meeting? Any other thoughts considering this is our first attempt at a meeting via the Webex? Well, this is our first Webex meeting. So hopefully we answered everyone's questions. As Mike said at the beginning, we are going to, it is being recorded and it will be posted on the city of Fort Worth website on the project page. If you want to refer back to any of the plans or any questions that came up. Mike, there is one additional question that just came in about holding future meetings in person. Okay. So that will all depend on how the world and the US shakes out and our state shakes out and our, I guess, Fort Worth shakes out with the COVID response and how our thing's doing. I don't believe Jeff, I don't know if anybody's brought any in-person meetings. I don't believe we've had any discussions on that yet. Correct? Correct. We have Webex meeting scheduled at least through August at this point. Obviously our preference is to always have an in-person meeting if we can. We like the interaction a lot better and we can have larger displays for people to see, but we don't have a timeframe on when in-person meetings will begin again quite yet. Okay. And there are the phone numbers and email addresses for both of us if in case anybody needs to see that one more time. Yes, and honestly, please reach out the best way for us to have a project that benefits all and everybody agrees with is if we hear back, it's always the most difficult thing is when we hear after the project what we could have done. It's a lot harder to correct things once you hear it after it's done. So that's the purpose of this is to get the input while we're still have the opportunity to make changes and adjust. So please reach out. And I know we fully understand this outfall is a big issue. So we're gonna do our best to get everybody on board with this as best as best as we can. So I guess please be patient but just keep continue to reach out to us. And we thank you. Thank you for your time. And with that, I'm gonna stop the recording and we'll get posted.